This post intends to introduce a feature of SSSD, that, despite being around since the release of 1.9, is still not used as often as it should – the Active Directory backend.
Even though 1.9 was released more than a year ago, I still see many deployments configuring the pure LDAP backend when configuring an AD client machine. I'll try to explain the advantages of the AD backend compared to the LDAP backend, but in short, you should always use the AD backend when configuring SSSD with an AD server.
Below is a summary of the biggest advantages of the AD provider in my opinion. A more detailed description of the new features will follow in a next blog post.
The enrollment using realmd is easier and more secure
This is technically not a feature of the AD backend, but it's still worth noting.
There are several ways to enroll a Linux client machine to AD – generate a keytab on Windows, use Samba, etc. All of them require some amount of knowledge and manual tweaking – refer to the SSSD wiki page
for details. In contrast, realmd is a great tool written by a friendly upstream that reduces all that effort into a single line of shell command:
# realm join ad.example.com
You'd be queried for AD Administrator credentials by default, but any user authorized to join a client to the realm can be used. Realmd also supports one-time passwords and more. After the join finishes, the client machine will run the SSSD with the AD provider configured by default, but winbind is also available, if you prefer that option. Realmd is included in the last couple of Fedora releases, starting with Fedora 18. If you are running an older distribution, such as RHEL6, I'd advise to use the underlying client tool called adcli, which is available from EPEL.
The configuration is simpler
Even if you opt for manual configuration or have a client already joined to a domain, the simplified configuration might be of interest. While AD can be treated just as an LDAP/Kerberos combo, several configuration options need to be tailored in order to match what is stored on the server
For example, user objects in AD are of objectclass user. In contrast, the LDAP provider defaults to posixAccount. Active Directory is also case insensitive, which requires the use of the "case_sensitive" option. The AD provider already comes with all the defaults set out of the box, so the previously complex configuration can be simplified to:
id_provider = ad
The example above assumes that UIDs and GIDs are mapped automatically by the SSSD and the AD servers are autodiscovered from DNS.
AD specific features included
In comparison to using the generic LDAP and Kerberos providers, the AD provider allows the client machine to use several features unique to the AD backend. In particular:
- logins are faster as the AD provider can leverage the special tokenGroups feature
- the client machine is able to update or refresh its DNS records
- the NetBIOS domain name can be autodiscovered and used in both lookups and output format (getent passwd AD\\Administrator now works)
- clients are able to automatically discover the closest AD server to connect to using the 'sites' feature of AD
- the AD provider automatically discovers trusted domains in the same forest, allowing all users from the same forest to log in to the machine
- expressing access control with an LDAP filter was made much simpler with a new configuration option
- custom UPN suffixes, also known as Enterprise Principals are supported by default
The next post will illustrate these AD specific features in more detail.