Sysadmin

7664 readers

2 users here now

A community dedicated to the profession of IT Systems Administration

No generic Lemmy issue posts please! Posts about Lemmy belong in one of these communities:
!lemmy@lemmy.ml
!lemmyworld@lemmy.world
!lemmy_support@lemmy.ml
!support@lemmy.world

founded 1 year ago

MODERATORS

DarraignTheSane@lemmy.world

00Lemming@lemmy.world

L3s@lemmy.world

Are we the only shop with constant login bullshit on Office 365 desktop apps? (lemmy.world)

submitted 1 year ago by HC4L@lemmy.world to c/sysadmin@lemmy.world

13 comments fedilink hide all child comments

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?

you are viewing a single comment's thread
view the rest of the comments

[–] Snowplow8861@lemmus.org 3 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] HC4L@lemmy.world 2 points 1 year ago (1 children)

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..

[–] Snowplow8861@lemmus.org 2 points 1 year ago

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.