Anja Kaiser; Fotolia

Single sign-on with SSSD, LDAP, and Kerberos

Cached Tickets

Article from ADMIN 02/2010

By Thorsten Scherf

Mobile users need a connection to the LDAP and Kerberos servers to authenticate over insecure IP networks. The System Security Services Daemon (SSSD) helps plug this gap.

When a user logs in to a Linux system, the Name Service Switch (NSS) is responsible for finding the user account in the user database. Traditionally, the user database is the /etc/passwd file. If the account exists, the PAM subsystem authenticates the user, for example, by comparing the password entered by the user with its counterpart in the /etc/shadow file. This approach quickly reaches its limits, especially if a large number of user accounts exist. In this example, the accounts would need to be created on every single machine because the user and password databases only exist on the local filesystem.

Objects All Around

The problem of user account management can easily be solved using a centralized directory service, such as NIS or LDAP, in which the user credentials are not stored locally but on a central server. Systems that can access the central server can thus query the server when a user tries to log in. Because NIS isn't exactly renowned for providing a secure environment, I'll be using the LDAP directory service in this article. In contrast to NIS, LDAP uses a hierarchical tree structure to store information in attributes.

If you combine these attributes, objects are the result: user objects, for example. A schema defines which information (attributes) can be used together.

An /etc/dirsrv/schema/10rfc2307.ldif schema file on the 389 directory server defines the required attributes for RFC 2307- and 2307bis-compliant user objects. The object class from which user accounts are derived is called posixAccount (Listing 1).

Listing 1

Definition of posixAccount