I was experiencing major issues with SSSD today where newly created users were unable to logon. After troubleshooting I found that the issue was in the AD user object security permissions. Seems like someone from my team recently changed the permissions for authenticated users and unchecked the read checkbox.
So my questions is which user does a Linux server that was joined to a domain with SSSD use to authenticate and retrieve AD objects information? As the users in the ou where the read permissions have been revoked for authenticated users are very critical, I would like to know what user is used to authenticate by SSSD. Could it be the computer object of the Linux server that requires the permissions?
The weird thing is that when I enable read permissions temporarily, id the user after which all works fine. Then I uncheck the read permissions for authenticated users and it seems everything keeps working.. (Of course after emptying the sssd cache) Any insights on which permissions are minimum required by which user are welcome.
We discovered it is the AD computer object which actually authenticates. Giving this object read permissions on the user enables the id command to retrieve the groups. The question is which permissions are minimally required so the id command can get all the groups?