Introduction

In Part 1 of 4 - SSSD Linux Authentication: Introduction and Architecture I covered an introduction on SSSD and an architecture overview with details on the flow of how it all works.  In this part I am going to cover the LDAP Identity Store details required for SSSD.

LDAP Identity Store Schema Requirements for SSSD

A UNIX user account typically requires a uid, a gid, a home directory, a login shell, and a password.  Minimally, a uid (User ID) and gid (Group ID) are required to authenticate.  The gid (Group ID) will map back to a primary group plus potentially several groups, but when using SSSD the group(S) will be stored in the LDAP Identity store.  All these minimal values will be mapped to the respective LDAP identity store used by SSSD.  From a LDAP identity store perspective groups used by SSSD can be separated into two main categories, Active Directory and other LDAP stores.  Microsoft has special considerations that have to be dealt with vs other LDAP identity stores like OID, OUD, ODSEE, etc.  The following sections help understand the idiosyncrasies in the two LDAP identity store categories.

Microsoft Identity Management for UNIX

SSSD provides a couple of options for LDAP schema needs when working with Active Directory.

• Option #1 – Microsoft Identity Management for UNIX https://msdn.microsoft.com/en-us/library/cc731178(v=ws.11).aspx

• Option #2 – SSSD ldap_id_mapping

As pointed out in the earlier section, a user minimally should have a User ID (uid number), a Group ID (gid number), a login shell, and home directory.  All these values need to be stored in Active Directory.  With option 1, Microsoft has a legacy package called Identity Management for UNIX that extends the Active Directory schema with UNIX type attributes.  Note that Microsoft points out the following warning.

As an alternative, SSSD also provides an option 2, ldap_id_mapping, which can map to existing Active Directory schema attributes that dynamically map a user to its objectSid including a primary group using the primaryGroupID attribute. Then there are a couple SSSD parameters that can be configured to dynamically set the users home directory and default shell. Which option you decide depends on whether you have an existing on-premise implementation that has used PAM and Active Directory, and are migrating to OPC or this is a new implementation with no legacy configurations to deal with.

For example, in option 2, using ldap_id_mapping SSSD uses an algorithm to come up with a unique number used for the User ID and Group ID based on the Active Directory objectSid. Take the following alternative sssd.conf configuration using ldap_idp_mapping.

          ldap_user_objectsid = objectSid
          ldap_group_objectsid = objectSid
          ldap_user_primary_group = primaryGroupID
          case_sensitive = false
          ldap_id_mapping = true
          fallback_homedir = /home/%d/%u
          default_shell = /bin/bash

Notice the ldap_user_objectsid and ldap_group_objectsid attributes map to an attribute objectSid, which Active Directory automatically assigns a unique value; see the graphic below.

When a user logs in, SSSD will grab the objectSid and using an algorithm SSSD assigns a unique number, take the following terminal window for the user above.

    [dang@oel6 ~]$ id uid=1078201115(dang) gid=1078200513(domain users) groups=1078200513(domain     users),1078201105(unix) 

And since the sssd.conf is configured with “fallback_homedir = /home/%d/%u”, the user will dynamically be assigned a home directory under /home, domain, and username as follows. The shell will also default to bash as configured “default_shell = /bin/bash”.

    [dang@oel6 ~]$ pwd /home/AD/dang 

Since UNIX depends on the User ID and Group ID for security reasons to protect files and folders especially for your home directory, you will need to decide whether option 1 or 2 is the right path. If this is a new deployment, option 2 is highly recommended. Later in this article actual configuration options will be provided.

Non-Microsoft; OID, OUD, ODSEE, etc.

All Non-Microsoft LDAP identity stores include schema that supports UNIX attributes. This includes the following objectclasses.

     ☑ posixAccount – Used for UNIX user attributes
     ☑ posixGroup – Userd for UNIX group attributes

Typically when describing a user or group, the object classes inetOrgPerson and groupOfUniqueNames are used respectively. However, neither posixAccount or posixGroup are part of the inetOrgPerson and groupOfUniqueName structural classes. Therefore, you can either add posixAccount to a user’s object in order to get uidNumber, gidNumber, loginShell, and homeDirectory, and add posixGroup objectclass to a group to get the gidNumber attribute. Alternatively, you can create a custom object class and incorporate both needed classes.

For example, you could create acmePerson and include inetOrgPerson and posixAccount classes to get all the needed attributes to describe a user that includes UNIX attributes. Similar for a custom group class, use both groupOfUniqueNames and posixGroup. More on mapping the appropriate attributes later in the implementation sections.

UNIX UID and GID Numbers

In UNIX when a user is created they typically will automatically be assigned a user ID number and a group ID number. That said, every Linux user must have a UID and a primary GID to successfully authenticate.

id <user>
Example: id adina
uid=20003(adina) gid=95001(Linux) groups=95001(Linux)

When using SSSD, the uidNumber and gidNumber come from the LDAP identity store. Once a user logs into a system or service with SSSD, it caches the user name with the associated UID/GID numbers. The UID number is used as the identifying key for the user. If a user with the same username but a different UID attempts to log into the system, then SSSD treats it as two different users with a name collision. This has nothing to do with SSSD, this is how UNIX works.

It is important to understand that SSSD does not recognize a UID number change, it only sees it as a different and new user, not an existing user with a different UID number. If an existing user UID number changes they will be denied login. This also has the same impact with accounts used by client applications which are stored in an identity store. If a user does have a UID change someone as root will need to run the following command to remove the cache. Now the user can try to login again.

[root@host]  sss_cache –u adina

UNIX Home Directory and Login Shell

In UNIX a home directory, also called a login directory, is the directory on the operating system that is the user’s personal repository. It is also the directory the user first lands in after logging in. When using SSSD, the home directory is defined in the sssd.conf using the parameter ldap_user_home_directory which map to the appropriate LDAP attribute. Then for the UNIX shell, this is a command-line interpreter, that provides the user their command line user interface. When using SSSD, the ldap_user_shell parameter is used in sssd.conf to map to the corresponding LDAP identity source attribute and value. Depending on the LDAP identity store used, the attributes for home directory and login shell will be mapped in the /etc/sssd/sssd.conf file. More details on how this will all be configured later in the implementation sections.

TLS/LDAPS Requirements for SSSD

Because SSSD sends sensitive information across the wire between the Linux server and LDAP identity store when logging in such as a password, encrypting the LDAP communication is required by SSSD using either SSL or TLS. However, TLS is highly recommended and will only be used in articles from this point forward. SSL has many security vulnerabilities such as Heartbleed, POODLE, DROWN attack, etc. and from a security best practice it is highly recommended to avoid SSL and use TLS instead.

Since there are many ways to generate and configure SSL/TLS certificates for LDAPS, this effort is out-of-scope in this article. Just as a note, the encrypted traffic going from SSSD to LDAP does not need be all the way to the LDAP Identity Store, it can be terminated at a load balancer if that is the desired architecture. The only requirement is LDAP communication going from SSSD needs to be encrypted otherwise authentication using SSSD will not work.

Summary

In this article, I covered all the important aspects of what SSSD looks for in the LDAP Identity Store. Whether you are using Active Directory, Oracle Unified Directory, Oracle Internet Directory, etc., all will require some minimum posix type attributes to enable authenticating to Unix. Knowing what SSSD needs for mapping UNIX attributes for SSSD is very critical.  In the next article, Part 3 of 4 – SSSD Linux Authentication: Implementation Step-by-Step Guideline, I will provide step-by-step on how to deploy SSSD.