Description of problem: When sssd is running as unprivileged user 'sssd' , Below error can be seen sssd status -- v 10 10:06:30 example.com sssd[be[example.com]][42908]: krb5_kt_start_seq_get failed: Permission denied Nov 10 10:06:30 example.com sssd[be[example.com]][42908]: Failed to read keytab [FILE:/etc/krb5.keytab]: No suitable principal found in keytab -- Version-Release number of selected component (if applicable): How reproducible: Easily Steps to Reproduce: 1. Add user = sssd in [sssd] section of /etc/sssd/sssd.conf 2. Restart sssd service 3. Actual results: Errors in sssd service status -- v 10 10:06:30 example.com sssd[be[example.com]][42908]: krb5_kt_start_seq_get failed: Permission denied Nov 10 10:06:30 example.com sssd[be[example.com]][42908]: Failed to read keytab [FILE:/etc/krb5.keytab]: No suitable principal found in keytab -- Expected results: No such errors in sssd service status Additional info: Issue is resolved after changing the permissions or ACLs on /etc/krb5.keytab.
Hi, the issue happens when SSSD tries to access other domains in the AD forest. For the configured domains the keytab is read at startup when the backend is still running as root. The other domains are discovered at runtime when the backend already runs as 'sssd' user and use the same code-path to check if the keytab contains the needed principals. One possible solution is just to skip the check in this case, in the worst case we would fail later when ldap_child tries to get a Kerberos ticket. Another solution would be to use ldap_child to check the principals since this is installed with the SUID bit set when SSSD should run as non-root user. There might be other solutions as well. bye, Sumit
Quality Engineering Management has reviewed and declined this request. You may appeal this decision by reopening this request.