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?


Unless you specified ldap_default_bind_dn and ldap_default_authtok in your sssd.conf, it will default to an anonymous bind to the specified LDAP server to retrieve the schema and objects. Anything else, like a logon, will use the provided credentials.

  • Thanks for your answer Daniel. I'm using 'id_provider = ad'. Does ldap_default_bind_dn and ldap_default_authtok work with the ad id provider? (I can only find examples with the ldap id provider)
    – willemdh
    Aug 10 '16 at 7:08
  • In the meantime we actually discovered it is the ad computer object which authenticates, So this is not an anonymous bind actually? When we give read permissions to the Linux computer object, everything works as expected.
    – willemdh
    Aug 10 '16 at 10:05
  • Sorry, I wasn't clear. Anonymous bind is used for non-sensitive things related to retrieving schema and objects. Authentication is something that computer accounts do just like a user account, which you discovered. I was trying to answer both sides of the question. Glad you got it going. Aug 10 '16 at 15:00

After a lot of research we discovered that (as I already mentioned in the question) it is the Linux server computer object that is actually authenticating. Granting read permissions on the user objects to the computer object enables id to work and retrieve all the user groups.

But as we didn't want to grant read on all users, after much trial and error we found that there is acutally only one mandatory required permission and that is Read remote access information. From the moment the Read remote access information checkbox is checked (see screenshot) it is possible to use the ìd command to get all the groups. SSSD is then able to check if the user is in the groups configured with the simple_allow_groups directive in /etc/sssd/sssd.conf

enter image description here

  • 2
    Yes, the AD provider uses the keytab to authenticate. In particular, it normally uses the principal that matches NETBIOSNAME$@AD_REALM.
    – jhrozek
    Aug 10 '16 at 13:34
  • Hi @willemdh can i know how to add "Read remote access information"? Because when i try to change permission, i can't find permission for "Read remote access information". Thanks Jan 20 '20 at 10:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.