jhrozek

Due to some technical issues we had when connecting Planet FreeIPA to livejournal and LJ being seemingly obsolete, I've moved my blog to Wordpress.

Please update your bookmarks!

Many SSSD users know that SSSD supports fail over from one server to another for authentication with services like su or ssh and even autodiscovers the Kerberos servers using DNS records.

But occasionally users would ask - OK, so SSSD lets me log in with another server but I also need to use kinit manually. Does kinit use the same server SSSD used? If so, how does kinit know which KDC SSSD uses?

The SSSD actually has a plugin that is able to tell what KDC or kadmin server to use for a particular realm. When SSSD discovers a Kerberos server, it puts the IP address of that server into a file stored under the /var/lib/sss/pubconf directory. The file that stores the KDC is called kdcinfo.$REALM and the kpasswd file is called kpasswd.$REALM. When SSSD switches to another Kerberos server during a fail over operation, a new IP address is generated in these files. Also, if SSSD goes offline completely, these files are removed, so that tools using libkrb5 only rely on other means of configuration, such as the krb5.conf file.

As noted above, the kdcinfo files are only refreshed during SSSD operation, like user login. This poses a disadvantage for systems that don't perform many operations using the PAM stack, because the server that SSSD discovered might go offline without SSSD triggering a fail over operation. For these environments, it's better to disable the kdcinfo files altogether by setting the krb5_use_kdcinfo option to False and relying on krb5.conf completely. We plan on improving the kdcinfo plugin in future upstream versions so that it plays better with these kind of setups.

The SSSD kdcinfo plugin even has a man page!

echo "search test.example.com" > /tmp/testresolv.conf
echo "nameserver 127.0.0.1" >> /tmp/testresolv.conf
LD_PRELOAD=libresolv_wrapper.so RESOLV_WRAPPER_CONF=/tmp/testresolv.conf ./dns_unit_test

echo "SRV _kerberos._tcp.example.com kdc.example.com 88" > /tmp/fakehosts
echo "A   kdc.example.com 127.0.0.10" >> /tmp/fakehosts

LD_PRELOAD=libresolv_wrapper.so RESOLV_WRAPPER_HOSTS=/tmp/fakehosts ./kinit_unit_test

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>

#include <netinet/in.h>
#include <arpa/nameser.h>
#include <arpa/inet.h>
#include <resolv.h>

int main(void)
{
        int rv;
        struct __res_state dnsstate;
        unsigned char answer[256];
        char addr[64] = { 0 } ;
        ns_msg handle;
        ns_rr rr;

        memset(&dnsstate, 0, sizeof(struct __res_state));
        res_ninit(&dnsstate);
        res_nquery(&dnsstate, "kdc.example.com", ns_c_in, ns_t_a, answer, sizeof(answer));

        ns_initparse(answer, sizeof(answer), &handle);
        ns_parserr(&handle, ns_s_an, 0, &rr), 0;
        inet_ntop(AF_INET, ns_rr_rdata(rr), addr, sizeof(addr));
        puts(addr);

        return 0;
}

gcc rwrap_example.c -lresolv -o rwrap_example

LD_PRELOAD=libresolv_wrapper.so RESOLV_WRAPPER_HOSTS=/tmp/fakehosts RESOLV_WRAPPER_DEBUGLEVEL=4 ./rwrap_example
RWRAP_TRACE(1970) - _rwrap_load_lib_function: Loaded __res_ninit from libc
RWRAP_TRACE(1970) - rwrap_res_nquery: Resolve the domain name [kdc.example.com] - class=1, type=1
RWRAP_TRACE(1970) - rwrap_res_nquery:         nameserver: 10.11.5.19
RWRAP_TRACE(1970) - rwrap_res_nquery:         nameserver: 10.5.30.160
RWRAP_TRACE(1970) - rwrap_res_nquery:         nameserver: 192.168.1.254
RWRAP_TRACE(1970) - rwrap_res_fake_hosts: Searching in fake hosts file /tmp/fakehosts
RWRAP_TRACE(1970) - rwrap_res_fake_hosts: Successfully faked answer for [kdc.example.com]
RWRAP_TRACE(1970) - rwrap_res_nquery: The returned response length is: 0
127.0.0.10

Centralizing sudo rules in a centralized identity store such as FreeIPA is usually a good choice for your environment as opposed to copying the sudoers files around - the administrator has one place to edit the sudo rules and the rule set is always up to date. Replication mitigates most of the single-point-of-failure woes and by using modern clients like the SSSD, the rules can also be cached on the client side, making the client resilient against network outages.

The first step is to load the sudo schema into the AD server. The schema describes the objects sudo uses and their attributes and is not part of standard AD installations. In Fedora, the file describing the schema is part of the SUDO RPM and is located at /usr/share/doc/sudo/schema.ActiveDirectory. You can copy the file to your AD server or download it from the Internet directly.

ldifde -i -f schema.ActiveDirectory -c dc=X dc=DOMAINNAME,dc=LOCAL

In my test, I used "ADSI Edit" again. Just right-click the SUDO container, select "New->Object" and then you should see sudoRole in the list of objectClasses. Create the rule based on the syntax described in the sudoers.ldap man page; as an example, I created a rule that allows the user called "jdoe" to run less, for instance to be able to inspect system log files.

dn: CN=lessrule,OU=sudoers,DC=DOMAINNAME,DC=LOCAL
objectClass: top
objectClass: sudoRole
cn: lessrule
distinguishedName: CN=lessrule,OU=sudoers,DC=DOMAINNAME,DC=LOCAL
name: lessrule
sudoHost: ALL
sudoCommand: /usr/bin/less
sudoUser: jdoe

sudoers: files sss

services = nss, pam, sudo

sudo -l

You should be able to see something like this in the output:
User jdoe may run the following commands on adclient:
(lcl) /usr/bin/less

Two interesting COPR repos with SSSD packages were made available recently.

For more details on the repos see the announcements on sssd-devel about both Stephen's and mine repos.

If you're adding a modern Linux client to an Active Directory domain, you really should be using realmd. It's easy to use, secure and does the right thing by default.

If you haven't heard about realmd already, check out the documentation. In a nutshell, realmd makes the client enrollment as easy as:

However, realmd depends on some software that is not available on stable platforms used in production, like RHEL-6 and its derivatives. Still, it's possible to use some of the components realmd builds on separately and have a reasonably user-friendly experience. In this blog post, I'll show you how, using a package called adcli, that is usually just a building block of realmd.

My test AD server domain is called win.example.com and the server that runs the domain is called server.win.example.com. For the test, I've used a mostly default CentOS 6.5 VM.

Typically, you'll want to point your Linux machine to the AD server for DNS:

Start the setup by enabling the EPEL repository and installing the 'adcli' package:

You can type just 'adcli' to get an overview of what commands adcli supports. We're interested in joining the client to the AD domain in order to be able to log in as users from Active Directory.

Now you should be able to find your domain already:

As you can see, adcli was able to discover quite a few details about my test domain, so it's time to join the client:

You'll be prompted for the Administrator password by default, but it's possible to specify another user with the -U option. See the adcli man page for full list of details.

The join operation creates a keytab the machine will authenticate with. When you inspect the with klist -kt, you should see several entries that contain you client hostname in some form. Here are the keytab contents on my test system:

It's recommeded to also configure /etc/krb5.conf to use the AD domain:

The final step is setting up the SSSD (or Winbind if you like) to actually make use of the keytab to resolve users. I'll show how to use the AD back end of SSSD as an example. Make sure sssd and authconfig are installed:

Unfortunately, authconfig in RHEL-6 doesn't support configuring the AD back end directly, so you'll have to do a bit of manual configuration. We can still use authconfig to set up the Name Service Switch and PAM stacks:

Now you should see 'sss' being present in /etc/nsswitch.conf and the pam stack configuration:

The final step is to configure the SSSD itself. Open /etc/sssd/sssd.conf and define a single domain:

Start the SSSD and make sure it's up after reboots:

You should now be able to log in as an AD user just fine:

For more information on the SSSD ad provider, see the SSSD wiki page or just sssd-ad the manual page.

Faster logins

Dynamic DNS updates

Dynamic NetBIOS name discovery

DNS site discovery

Support for trusted domains in the same forest

Support for enterprise logins

A simplified LDAP access control mechanism

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

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 side.

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:

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

• 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

In Fedora 17, we are introducing a new feature - the SSSD gets an ability to cache automounter maps and map entries stored in a remote database the SSSD can access, which is mostly LDAP. Because there is no user-facing documentation available to describe how this feature works, I decided to introduce it in a little more detail in this blog post. The post is quite verbose as it explains the native LDAP case as well - if you are familiar with automounter and how automounter is configured to access map in LDAP, feel free to skip to the last section.

The automounter is a very useful software that lets the user access removable media or network shares without explicitly mounting them and unmounts them when they are not needed. The user would simply access the directory where the remote file system is located and the automounter then takes care of mounting the correct share with the desired options. Obviously, the automounter needs to know which share should be mounted from which location. The configuration files for autofs are called maps and are similar to /etc/fstab at a high level. The main, top-level map is called the master map and is typically located in /etc/auto.master. There's quite a lot of resources on automounter on the Internet, the reader may continue to the Red Hat Documentation, for example.

When the maps are stored in files, the administrator faces a problem on a large network - he needs to distribute the files to all the hosts that he manages on the network. One possible solution is to use a tool such as puppet or cfengine to help distributing the files. Another solution is to get rid of the files altogether and fetch the maps from a centralized directory, LDAP in particular. The automounter then only needs to know the location to download the maps from.

Accessing the LDAP maps using the SSSD

• unified configuration of LDAP parameters such as the servers used, timeout options and security properties at one places (sssd.conf)


• autofs would take advantage of the advanced features SSSD has such as server fail over, server discovery using DNS SRV lookups and more


• only one connection to the LDAP server open at a time resulting in less load on the LDAP server and better performance


• caching of the data - again, less load on the LDAP server and better performance on the client side as the client wouldn't have to go to the server with each request

A hands-on example: migrating the client configuration to use the SSSD

1. Create a new [autofs] section in the /etc/sssd/sssd.conf config file. Leaving it empty will use the defaults which should be good enough for most deployments. The sssd.conf manual page contains the single currently available option.
   
   [autofs]
2. The services parameter in the [sssd] section must be amended to include the autofs service as well:
   
   services = nss,pam,autofs
3. The last parameter in the sssd.conf file that might optionally need amending is the search base. The default is to use the ldap_search_base parameter but you can also specify the search base using the ldap_autofs_search_base option:
   
   ldap_autofs_search_base="cn=automount,dc=example,dc=com"
4. The last step during the client configuration is to tell autofs to contact the SSSD for automounter maps. This is done in by changing the automount: line in the /etc/nsswitch.conf config file to say sss instead of ldap:
   
   automount: files sss
5. Restart the SSSD:
   
   service sssd restart