Update active-directory-client.md

[TimInLasVegas]

Without ad_gpo_access_control = permissive in the [domain] section of the SSSD conf I could not log in to my Server 2022 AD from PopOS. I've found dozens of places on the internet where people have complained that they can not log in, just like the issue I had. None of those people seemed to find the fix. If this isn't added we should at least leave it as a comment for those who can't log in on their AD instance.

[ahoneybun]

@jacobgkau is this correct?

[jacobgkau]

I set up a Windows Server 2022 virtual machine with an Active Directory domain (since this article was last tested with Windows Server 2019), and I was unable to recreate the failure to log in with the current instructions (without this extra line.)

Additionally, SSSD documentation (as well as Red Hat documentation) indicates that permissive is the default value for this setting, so we shouldn't need to set it manually.

@TimInLasVegas Can you please elaborate on your Windows Server 2022 configuration, as well as your Pop!_OS configuration besides what the support article covers? Can you link to some of the "dozens" of related complaints you're referring to?

[jacobgkau]

Looking through the comments of my personal YouTube video on this topic, one Ubuntu user said adding ad_gpo_ignore_unreadable = True and ad_gpo_access_control = permissive to the configuration is supposedly required for Ubuntu 20.04 and above. However, I just confirmed that vanilla Ubuntu 22.04 also doesn't need the option to work with Windows Server 2022.

I am seeing some SSSD bug reports searching for the two settings that might point me towards a Windows Server configuration that will trigger the issue.

[jacobgkau]

I tried creating a group policy object and removing the Authenticated Users group from the security filter so a regular user can't read the object (which Windows Server explicitly warns about), but I still couldn't recreate the issue.

If I remove Authenticated Users from the Default Domain Policy object (which Windows Server still warns about), then I can't log in; adding the ad_gpo_access_control = permissive line allows me to log in then. (I found references to the default being changed away from this in Focal.) So that is a situation where this line is helpful, although it seems Microsoft considers this Windows Server configuration to be invalid: https://support.microsoft.com/en-us/topic/ms16-072-security-update-for-group-policy-june-14-2016-7570425d-d460-3003-b2ac-a464c874725d

(I tried testing with Domain Computers added instead of Authenticated Users, since that is the other possible configuration that Microsoft considers valid, but it still works without the extra configuration line.)

[ahoneybun]

@TimInLasVegas it sounds like from @jacobgkau 's testing it could be a configuration on your end, is that correct @jacobgkau ?

[jacobgkau]

Unless someone can provide a different way to recreate the issue from what I found, then that would seem to be the case. The handful of people I found discussing this workaround does make me think a note about checking the server-side configuration or else adding the option might still be useful, though (just in a separate code block from the recommended configuration.)