Introduction to network user authentication with SSSD

Note:
This documentation has moved to a new home! Please update your bookmarks to the new URL for the up-to-date version of this page.

The System Security Services Daemon (SSSD) is actually a collection of daemons that handle authentication, authorisation, and user and group information from a variety of network sources. It’s a useful tool for administrators of Linux and UNIX-based systems, particularly in enterprise systems which may need to integrate with other directory, access control and authentication services.

Common deployment scenarios

At its core, SSSD has support for a variety of authorisation and identity services, such as Active Directory, LDAP, and Kerberos. See the following guides to discover how to set up SSSD with…

Integration with PAM and NSS

SSSD provides Pluggable Authentication Modules (PAM) and Name Service Switch (NSS) modules to integrate these remote sources into your system. This allows remote users to login and be recognised as valid users, including group membership. To allow for disconnected operation, SSSD also can also cache this information, so that users can continue to login in the event of a network failure, or other problems of the same sort.

Troubleshooting

If you have problems with your SSSD setup, you can use some of the tips contained in our SSSD troubleshooting guide to discover the cause.

1 Like

I have had to add this to my /etc/sssd/sssd.conf file to get supplementary groups to return from Active Directory:

ldap_use_tokengroups = false

I guess it depends on the version of the AD server. The sssd-ldap manpage says:

ldap_use_tokengroups
This options enables or disables use of Token-Groups attribute when performing
initgroup for users from Active Directory Server 2008 and later.

Default: True for AD and IPA otherwise False.

Hi,

I am trying to join my local ubuntu 22.04 system to the Microsoft AD server. I followed the official docs along, but I am failing after trying to join the realm.

I am stuck at:

root@pilot:/etc/sssd# sudo realm join -v -U admin  example.muc
 * Resolving: _ldap._tcp.example.muc
 * Performing LDAP DSE lookup on: 10.51.49.10
 * Performing LDAP DSE lookup on: 10.51.49.20
 * Successfully discovered: example.muc
Password for admin:
 * Unconditionally checking packages
 * Resolving required packages
 * LANG=C /usr/sbin/adcli join --verbose --domain example.muc --domain-realm EXAMPLE.MUC --domain-controller 10.51.49.10 --login-type user --login-user admin --stdin-password
 * Using domain name: example.muc
 * Calculated computer account name from fqdn: PILOT
 * Using domain realm: example.muc
 * Sending NetLogon ping to domain controller: 10.51.49.10
 * Received NetLogon info from: dc.example.muc
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-xiWRcH/krb5.d/adcli-krb5-conf-IhNzhN
 * Authenticated as user: admin@example.muc
 * Using GSS-SPNEGO for SASL bind
 * Looked up short domain name: EXAMPLE
 * Looked up domain SID: S-1-5-21-1909716060-53967329-2664983961
 * Using fully qualified name: pilot.example.muc
 * Using domain name: example.muc
 * Using computer account name: PILOT
 * Using domain realm: example.muc
 * Calculated computer account name from fqdn: PILOT
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * A computer account for PILOT$ does not exist
 * Found well known computer container at: CN=Computers,DC=example,DC=muc
 * Calculated computer account: CN=PILOT,CN=Computers,DC=example,DC=muc
 * Encryption type [3] not permitted.
 * Encryption type [1] not permitted.
 * Created computer account: CN=PILOT,CN=Computers,DC=example,DC=muc
 * Sending NetLogon ping to domain controller: 10.51.49.10
 * Received NetLogon info from: dc.exampple.muc
 ! Couldn't set password for computer account: PILOT$: Cannot contact any KDC for requested realm
adcli: joining domain example.muc failed: Couldn't set password for computer account: PILOT$: Cannot contact any KDC for requested realm
 ! Failed to join the domain
realm: Couldn't join realm: Failed to join the domain

When I try kinit admin@example.muc, I get a valid ticket (klist).

I checked firewall, traffic is passing. nc 10.51.49.10 88 works.

I did some research, but I was not able to find the core issue.