Scientific Linux 6 (and, by extension, RHEL6) authentication woes

Since no-one seems willing to fork out the cash for RHEL, yet management insist on using CentOS as “our skills are with RedHat”, and there is no sign yet of CentOS6 I have been doing some experimenting with Scientific Linux 6 (which is also a RHEL rebuild).

Configuring the new sssd daemon to do AD authentication seemed straightforward enough until I hit an interesting problem. It would appear that, beginning with RHEL6, RedHat has split /etc/pam.d/system-auth into /etc/pam.d/system-auth and /etc/pam.d/password-auth. In of itself this is not a problem HOWEVER I have also discovered that, out of the box, GDM uses the /etc/pam.d/gdm-password stack (which includes password-auth) and gnome-screensaver uses the /etc/pam.d/gnome-screensaver stack (which includes system-auth). The result of this is that if I configure system-auth only (which is what the RHEL6 deployment guide says to do[0] then I cannot login to GDM. If I set up password-auth only (described in the migration guide[1] as for “remote services”) I can login to GDM but once my session is locked with gnome-screensaver (either manually or by the screensaver timeout (which is on and locks by default) I cannot unlock it from the prompt which appears when I click the mouse or touch a key (although I can click “switch user” to get back to GDM where I can unlock it). Setting both up seems counter-intuitive if I only want to configure local access and ‘password-auth’ is for remote services.



One of my colleagues gave me a VMWare image to use to test authenticating Linux (CentOS in this case) with Active Directory. Unfortunately the image in question is about 10GB and after the existing images on the machine there was not enough for it in /var (a 17GB partition on a 20GB disk). As I could not find any more space on the existing drive I clearly needed to add another disk to the machine. Three dead disks later I finally found a (250GB! – effectively winning the hard-drive lottery) hard disk which no-one was using. Now just to move /var to the new disk.

I partitioned and formatted an 80GB partition, mounted it and copied the existing contents of /var accross. One edit to fstab later, I rebooted. The disk mounted fine, but various services refused to initialise with “permission denied” errors on /var. I checked the permissions against the old /var and they appeared to be identical. Some head scratching later I decided to go an ask the advice of one of my colleagues. He was equally bemused, but suggested that I tar up the old /var and untar it over the new partition incase the copy had not preserved the permissions (even though it had been told to, and they appeared to be correct). I did this however it had no effect. When I returned to my colleagues office, another one of my colleagues was talking to the first and the first suggested that he take a look. He had a quick glance at the problem and asked if SELinux was enabled. It was. One quick `restorecon -R /var` later everything worked. We then proceded to have a rant from colleague #2 about how Fedora and RHEL now had SELinux in enforcing mode by default where as it used to just warn by default, which was better in a production environment where it needs to be run in warning only mode for a while to check nothing is hitting it that should be allowed. Still it is all good fun.