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.

Samba, SELinux and the homes share

As has been documented here and many other places, on Redhat, CentOS, Fedora and other distros that come with SELinux enabled, you have to enable the SELinux boolean samba_enable_home_dirs if you export the homes share. I did this but I still could not connect to the share. The usual error message is NT_STATUS_BAD_NETWORK_NAME.


It turns out that you need samba_export_all_ro or more likely, samba_export_all_rw enabled to mount the share. This was on CentOS 5.5. It could be that on this distro and version both come disabled by default.


Make sure though that SELinux is the cause. There are many other reasons for NT_STATUS_BAD_NETWORK_NAME. A quick way to check is to set SELinux to permissive temporarily to attempt the connection.

Force yum to determine the fastest mirrors again

We are going to ship this CentOS machine overseas where the fastest mirrors will be different. We want yum to work that out on deployment there. A quick search of the files in the package yum-fastestmirror found the cache file: /var/cache/yum/timedhosts.txt


Just delete or rename this file and yum will do a speed test the next time it is run.


The plugin yum-fastestmirror appears to be an EPEL addon, so may not be installed by default on RHEL or Fedora.

Building openconnect for RHEL 5

This blog entry is of historical interest now. If you just want openconnect ready to run for RHEL/CentOS/clones, you can get openconnect 4.0 from EPEL now, thanks to David Woodhouse. (2012-07-26)

Openconnect is an open source client that can connect to Cisco's AnyConnect SSL VPN. There are packages for Fedora but none for RHEL 5. I needed one (actually for CentOS 5) so I set myself the task of building it from the latest Fedora 18 source RPM.


First of all install mock from the EPEL repo. You will need to track down the latest version of Mock 1.0, as Mock 1.1 has Python 2.5 constructs which won't work on RHEL 5.


You can't just do a mock rebuild right away. The Fedora SRPM has an MD5 sum which causes an error when extracting on RHEL 5. In any case we need to make some edits to the spec file. So first extract the Fedora 18 openconnect SRPM in the standard RHEL area, /usr/src/redhat:


rpm -i --nomd5 openconnect-...src.rpm


Now edit the spec file and remove the dependency on libproxy and change vpnc-script to vpnc. Also change the openssl dependency to the latest available for RHEL 5. RedHat keeps the version number the same while backporting fixes so it's ok that the required version decreases.


Create a new SRPM with


rpmbuild -bs openconnect.spec


Do the mock build on the new SRPM


mock openconnect-...src.rpm


You will encounter missing dependencies, so use tell mock to install those in the fakeroot and try again. Eventually you will get a binary RPM in /var/lib/mock/epel-5-x86_64/result (i386 for 32-bit of course).


Unfortunately the associated NetworkManager-openconnect cannot be ported to RHEL 5 due to requiring higher versions of X libraries. However it isn't too unfriendly to run openconnect from the command line (with root privilege, as it configures a TUN device):


openconnect ip_address_of_gateway


and it will prompt you for the username and password. You may want to look at command line options of openconnect to see what else is needed.


Probably the best you can do to make it user friendly is to use sudo to run it, and then create a GNOME or KDE launcher to run a terminal running it.