Many environments use an LDAP server to manage user and group accounts. Often, these servers will also be used for user authentication. However, this setup assumes that the user objects in LDAP have a password attribute. Of course, this attribute requires special protection. Only the user and an LDAP administrator should be allowed to change it. Appropriate access control lists make this relatively easy to achieve.

Problem Password

Nevertheless, user authentication based on the password attribute is not without risk. In the simplest case, it is handled by a Simple BIND operation. This involves the user password crossing the wire in clear text to the LDAP server, which then attempts to authenticate the user with the supplied password. If this step succeeds, the user is logged in to the client system; otherwise, an error message is returned. A secure configuration thus requires the user password to be transferred via a secure communication channel in each case, which could be implemented at the application level using SSL/TLS, for example.

In addition to the Simple BIND method, LDAPv3 supports authentication based on SASL (Simple Authentication and Security Layer, RFC 4422). This approach includes a whole range of methods for verifying a user – for example, using a Kerberos ticket or an X.509 client certificate. However, setting up and configuring such an environment is not always easy, partly because it assumes proper mapping between the user object in LDAP, which is represented by a Distinguished Name (dn) and the matching Kerberos principal or X.509 client certificate.

Alternatively, it is possible to perform authentication directly via a Kerberos server and only query the LDAP server for the user's account details. However, such a setup is quite complex and unwieldy; anyone who has been through the pain of using the Kerberos client tools will know what I'm talking about.

In a previous article [1], I mentioned the open source FreeIPA project [2], which has set itself the goal of being an easy to configure but still secure identity management solution for Linux and Unix environments. Of interest is how successful the transition is from an existing LDAP server to the FreeIPA Identity Management Solution. A few points need to be considered for the migration:

• How to migrate existing user and group objects.
• How to migrate user passwords.
• Which clients will be accessing the new identity management system?

FreeIPA has its own command for migrating users and groups:

ipa migrate-ds ldap://ldap.tuxgeek.de:389

This call migrates all the users and groups from two containers: ou=People and ou=Group to the local FreeIPA system. If the users and groups are stored in other containers, they also can be migrated using the --user-container and --group-container options. If only objects with a specific object class are to be transferred to the new system, the options are --user-objectclass and --group-objectclass. This is especially useful if users or groups exist in the containers, but you do not want to have them on the new system and can identify them on the basis of a specific object class.

Here is a more complex example:

ipa migrate-ds --user-container=emea-users --group-container=emea-groups --user-objectclass=employee --group-objectclass=groupOfNames,groupOfUniqueNames ldap://ldap.tuxgeek.de:389

If you want to exclude individual users or groups, you can do so on the basis of user and group names. The options --exclude-users and --exclude-groups help you do this. Other interesting options are --user-ignore-objectclass or --user-ignore-attribute, which let you exclude individual attributes or object classes from the migration. This is especially useful if the information is no longer needed on the FreeIPA system. Corresponding parameters exist for groups, and

ipa help migrate-ds

provides an overview of the options.

Migrating user passwords to the FreeIPA system is more complex. On the LDAP server, the passwords usually exist as a hash in the userPassword attribute; sometimes passwords are in plaintext format. However, FreeIPA uses Kerberos to authenticate the user. Again, a number of approaches exist for producing a corresponding Kerberos hash for the migrated user accounts:

• Users are forced to change their passwords after the migration. In this case, an appropriate Kerberos hash is then created on the basis of the changed password.
• Users are prompted to visit a migration web page on the FreeIPA system and enter their passwords there. Afterward, a Kerberos hash is generated and stored on the directory server.
• Clients running the System Security Services Daemon (SSSD) as a client component can fall back to FreeIPA migration mode to generate a password hash for their Kerberos principal. Migration mode is activated on the FreeIPA server as follows:

ipa config-mod --enable-migration=TRUE

On the client system, the user then logs on in the normal way via the FreeIPA system, which uses Kerberos for authentication. This process fails, of course, because the migrated user account does not have a Kerberos hash at this time. The SSSD client then automatically goes through an LDAP Simple BIND login on the FreeIPA system with the password previously entered by the user. This is done through a secure TLS channel.

The configuration of this setup is done when configuring the SSSD client. The FreeIPA system intercepts the transmitted password, notes that (although the user has a Kerberos principal) they do not have a Kerberos password hash, and proceeds to generate one. The connection is disconnected, and SSSD, independently and completely transparently for the user, runs through a Kerberos-based login (Figure 1).

Figure 1: An application uses SSSD to authenticate; SSSD in turn communicates with the back end via a secure connection.

The latter variant is the most elegant solution for the migration of user passwords to the identity management system. The only prerequisite is that the SSSD is used on the client system.

Client Software

SSSD is the preferred way to integrate Linux systems into the identity management system because of its very simple approach to migrating passwords. SSSD also offers a variety of advantages. For example, it keeps the information received from the FreeIPA system in a local cache. Logging into the system is thus also possible if the client is offline. The cache contains not only users but also sudo and auto-mounter information.

Using SSSD, you can implement host-based access control rules and other security settings on a client, including, for example, evaluating SELinux user mappings or SSH host and user keys. The client provides a PAM interface (pam_sss) and an NSS interface (nss_sss) on the front end for this setup (Figure 1). On the back end, it can communicate with different providers – in this case, with the FreeIPA system. The configuration of the client is done with the ipa-client-install command.

If you want to connect older Linux systems, for which SSSD is not available, or other Unix machines to the identity management system, it is possible to implement the connection via the regular LDAP and Kerberos interface. Here the classic PAM and NSS libraries (pam_krb5 and nss_ldap) enter the scene. In this case, the advanced features of SSSD, such as caching account information, are not available.

I hope this article has shown you that migrating a plain vanilla LDAP-based user authentication system to a modern, easy-to-manage identity management system is not rocket science. If you need more information about the system discussed, see my previous article on SSSD [1].

The Author

Thorsten Scherf is a Senior Consultant for Red Hat EMEA. You can meet him as a speaker at conferences. He is also a keen marathon runner whenever time and his family permit.