Deploying SSSD for authentication against Windows AD in CentOS 6

In an earlier post I discussed in general terms deploying SSSD on CentOS 7 which is fairly straightforward once the right choices have been made.

I have now successfully deployed it on CentOS 6. This blog post by one of the authors of SSSD gave me the initial clues. The key point is that while sssd and associated packages are available on CentOS 6, realmd is not so you have to do those steps manually using adcli.

There was one big problem though, the join command didn't work for me! When it came to that step I got an error message saying I had insufficient permissions to modify the computer entry in AD. I tried various permutations but still got the same error.

Finally I decided to examine the progress messages of realm -v join on a CentOS 7 machine to see what it was doing under the hood. It turned out to be a command of this form:

net -s /tmp/sssd-smb.tmpfile ads join example.com

So it was using the Samba net command, not adcli for joining!

The temporary file providing the settings to net was of the form:

[global]
workgroup = EXAMPLE
netbios name = MYWORKSTATION-N
realm = EXAMPLE.COM
kerberos method = system keytab
security = ads

Note that the netbios name should be truncated to 15 characters. The reason net is used is explained in the last comment of this bug report.

Now I don't know if realm switched to calling net when it detected that adcli would not work, or uses net since that blog post was written, to satisfy servers that don't allow creation/modification of computer entries with LDAP. I think the latter because realmd comes from the CentOS repo while adcli comes from EPEL repo so can't be a dependency. I suppose I could look at the code.

The next command that realm runs is:

net -s /tmp/sssd-smb.tmpfile ads keytab create

Once that is done, you will be able to run klist -k and get output. Then follow the rest of the blog post to set up sssd. If you were running /etc/passwd authentication, remember to delete those entries in passwd, group, shadow, and gshadow so that they don't mask the user entries from AD. Restart nscd to flush any cached entries afterwards. In the long term you want to follow RedHat's recommendations referred to in my CentOS 7 blog post to disable nscd caching for user and group entries.

Dos and Don'ts deploying sssd for authentication against Windows AD

New: For deployment on Redhat/CentOS 6, see here.

sssd (and realmd) in RedHat/CentOS 7 offers the chance to use Windows as a single authentication base. The RedHat manual was the most useful but there were also good debugging tips on stackoverflow and similar forums. However in deploying sssd I found some things worked for me and some things didn't.

• Do harmonise all the Windows and Linux login IDs. If there are users with two different IDs, then they'll have to bite the bullet and accept the change of one ID. Unfortunately domain logins cannot have aliases.
• When you join Linux to AD using the realm command and an unprivileged account, you may encounter this 10 machine limit. Here's how to raise the limit.
• Do use ntpd to keep all the clients in time sync. Specify the domain servers as NTP servers in ntp.conf. I had an issue where one client wouldn't authenticate. All the config files were identical with a working client. Finally I realised I had not enabled and started ntpd. It turned out to be clock skew. Kerberos is sensitive to this.
• Do enable GSSAPI with MIC in sshd. It really works and you can use putty to ssh to the server without specifying a password provided the Windows user has authenticated to the domain.
• Do use AD security groups to restrict access to the Linux servers. Otherwise all AD users can login by default. This means that enrolling a new Linux user across all the servers is simply adding the user to your chosen security group. Create one if necessary. Oddjobd will take care of creating the home directory on first login, which is very nice. I used the simple access_provider. I couldn't get the ad access_provider and ad_access_filter to work, but this is probably because I couldn't work out the correct LDAP strings.
• You can also use a security group to specify who can have extra privileges in sudo.
• I used the deterministic hash scheme for mapping SIDs to UIDs because I didn't want to (and didn't have authority to) add attributes to the AD schema.
• When migrating existing user accounts, make sure you find all the places a user might have a file. Not just /home but also /var/spool/cron and /var/spool/mail. Kick all the users off and kill all of their processes before you do the chown. Since after the switchover the names will map to the new UIDs, you can cd /home and run a loop: for u in * do; chown -R $u $u; done. Also the cron and mail directories.
• If you have software that must have simple login IDs, i.e. fred and not fred@example.com, then you should set use_fully_qualified_names = False. This implies you cannot have a default_domain_suffix. If you have a single domain, then you don't need domain suffixes. If you have multiple domains, then this is beyond my knowledge. I found that some applications cannot handle usernames of the domain form. Even the crontab command will create and require cron files of the domain form if domain suffixes are enabled.
• I couldn't get the sssd idmap to work with Samba so I chose winbind. Also you have to use winbind if you have to support NTLM authentication.
• New: If you are running 32-bit applications, you should also install the 32-bit libsss* shared libraries corresponding to the 64-bit ones, otherwise those applications may not be able to get user account info via PAM. This showed up in icfb, an old 32-bit Cadence executable, that worked for local users (in /etc/passwd) but failed for SSSD authenticated users.
• New: If oddjob_mkhomedir doesn't work, as evidenced by no home directory created for a new login, check /var/log/messages. SELinux is probably blocking this. Either make the policy permissive, or create a policy for this.