We are facing constant problems with the desktop apps in O365, wheter it’s RDS servers that somehow are Azure joined by a user from login 1001 errors to modern authentication Windows that automatically disappear or other generic error 1001 logon bullshit. We have a tome of registry bullshit with shit like EnableADAL to deleting the AAD appx folder from the user profile and/or reinstalling it through Powershell and so it goes on… usually dicking around with these settings will make it magically work for a few weeks…
The amount of time this costs us and our customers is truly staggering, are we the only shop facing this?
Are you using Trend Antivirus? We just finished a months long fight of very similar symptoms, and it was that our antivirus was deleting the login tokens.
This is what it was for us too.
No sorry, we use the same config across the board so that wouldnt explain the randomness. Ill look into it though.
We used the same config everywhere, still got randomness. Can’t explain why. Good luck!
Don’t think I’ve seen that.
We have 500+ O365 licenses and are not seeing any login issues like you describe. We had some teams issues about a month ago but not across all apps.
I’ve run into a lot of issues stemming from people creating personal Microsoft with the same email as their O365 email(why Microsoft? Fucking why do we even allow this?)
So they’ll mess around and log into their personal on one app and their work email on another, and then everything goes to shit because I guess Microsoft doesn’t quite grasp that having two accounts to very similar systems that have the exact same username is asinine.
Anyway, make sure you remove every account from the system, including removing the device from any azure domain, rejoin, and hand hold users through signing it.
We had this a lot during Covid where people just registered free Teams accounts with their work e-mail adresses. These environments are super small so I will check it out to be sure!
Thanks for taking the time to reply!
We’ve had it cause all sorts of crazy fucking problems. Let me know if you figure it out
With 70k users we do see problems from time to time, but nothing too the level I would call it problematic.
Hey, sorry to say but not seeing this at all. About 60 customers, each between 30-200 staff, in Australia region. Almost all of them have reasonable conditional access policies managing maximum login times per app, requirements for device compliance for data sync and geo-restrictions and longer login times for known sites, as well as standard mfa requirements.
Id say there’s something else in your stack. We monitor many of our customers with 3rd party tools too, including Arctic Wolf for seim /SOC alerts and triage and isolation if AAD accounts are breached. Sentinel one with integration in aad too. Though personally I feel like most medium and small businesses would be better served with the already included defender for business. A topic for a different day.
But no unusual requirement for cleaning cache and such to ensure the policies we configure act as we expect.
I’ve seen different tenants act differently of course in the past. But nothing right now I can suggest. I’d personally start doing a/b testing and reviewing all logs relative and see what impact before and after has on logs.
Anyway sounds frustrating so good luck.
Thanks for you insight, your environment sounds ways more complex but then again, miles better configured.
After some research it now seems to point to a registry cleaning script used to clean up bizarre amounts of entries created by certain printer drivers that were added each time a user logs on or off.
We aren’t sure yet since it can easily not happen for a few weeks out of itself but fingers crossed!
Thanks for taking the time to respond as I have should way faster…
I’ve seen something similar to this before in remote desktop servers where user redirected printers end up bloating registries to the point login times exceed processing limits and so not all the configuration in the registry or group policy gets processed. Each redirected printer gets created and never pegged, and it’s unique to that rdp session so they are duplicated to infinity over time. Glad you found it out, the only point with the complexity is I was trying to explain that it being complex doesn’t mean it won’t be robust if it’s still implemented without conflicts so you can rule that out (if you’ve ruled out conflicts) . Sounds like you found the culprit in the end! Good work.
