Aug 3, 2012

Enable CentOS 5.8 GNU / Linux Authentication on Windows Domain

In case you should ever be finding yourself having to configure your CentOS 5.8 GNU/Linux machines to allow active directoy windows users to login to them, this post will help.

While there are a few ways to set this up, i.e., likewise-open (see beyondtrust.com), centrify (centrify.com), the built-in System, Authentication graphical controls in CentOS, etc., the method in this post focuses on touching just a few config files to enable active directory  authentication. K.I.S.S. is the way I like to roll.

Using the authentication methods below assume that you have already enabled services for Unix on your active directory server and that the users that would be logging in to CentOS have their Unix tab (on ad user and computers) populated with values.

The Authentication methods outlined here use LDAP and Kerberos. LDAP brings the UID/GID information (from the Unix tab in ad) for the user, and Kerberos provides for username/password authentication piece.

With the default install of CentOS 5.8, it's amazingly simple to setup authentication to your active directory for Unix-enabled ad users.

Here are the steps for enabling your CentOS 5.8 GNU/Linux computer to authenticate with active directory:

1.) Create a special user in active directory (e.g., ad-guest-01). Once you've created the user, add it to the group "Domain Guests", make it the Primary group, and remove all other group memberships (e.g., Domain Users should be removed).

2.) Make changes to the following configuration files on the CentOS 5.8 GNU/Linux machine as shown below:

##############################################################
#/etc/ldap.conf for connecting with Win-Server w/SFU Enabled #
##############################################################
base dc=yourcompany,dc=com
uri ldap://yourADserver.yourcompany.com ldap://yourADserver.yourcompany.com/
binddn ad-guest-01@yourcompany.COM
bindpw 
bind_policy soft
scope sub
pam_min_uid 1000
bind_timelimit 5 
timelimit 5
idle_timeout 3600
ssl no
referrals no
nss_base_group dc=yourcompany,dc=com?sub?&(objectCategory=group)(gidnumber=*)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute gecos cn
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uniqueMember member
nss_initgroups_ignoreusers root,ldap


##############################################################
#/etc/krb5.conf for connecting with Win-Server w/SFU Enabled #
##############################################################
#  Tip: You can use predefined DNS names for your kerberos,
#+ ldap (ad) servers to make future ad dc hostname changes
#+ less painful.

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = YOURCOMPANY.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 forwardable = yes

[realms]
 YOURCOMPANY.COM = {
  kdc = yourADserver.yourcompany.com:88
  kdc = yourADserver
  admin_server = yourADserver.yourcompany.com:749
 }

[domain_realm]
 yourcompany.com = YOURCOMPANY.COM
 .yourcompany.com = YOURCOMPANY.COM

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }


######################################################
#/etc/nsswitch.com for Win-Server w/SFU Enabled  Auth#
######################################################

passwd:     files ldap
shadow:     files ldap
group:      files ldap

#hosts:     db files nisplus nis dns
hosts:      files dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files     

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

netgroup:   files ldap

publickey:  nisplus

automount:  files ldap
aliases:    files nisplus


##############################################################
#/etc/pam.d/system-auth-ac for Win-Server w/SFU Enabled  Auth#
##############################################################
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_krb5.so use_first_pass
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
#The line below allows local user login
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_krb5.so use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
#The line below triggers creation of home-dir upon user first login
session     optional      pam_mkhomedir.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_krb5.so
session     optional      pam_ldap.so


If you want your windows users to be able to run sudo, run visudo as root, then add:

%Domain\ Users ALL=(ALL) ALL


Note: The above setting is just an example of how to add FULL CONTROL for the ad-based "Domain Users" to the sudoers file. Changes to the sudoers file can be more finely tuned to only allow certain programs. If user restriction is a concern for your situation, I suggest you research "sudoers" and find the more granular settings that are appropriate for your needs.

Speaking of security, something else to consider is that if the user can become root with sudo -s on the machine, they will then be able to su and be seen as that user as far as the local machine is concerned. You can force them to authenticate (even as root) by commenting the line below in /etc/pam/su, but if they are root - they can still change it back:
vi /etc/pam.d/su
#auth sufficient pam_rootok.so

That's it. Reboot your CentOS, then you should be able to login as your windows user on the box. Feel free to leave a comment below with any suggestions or questions.


Cheers!
Shannon VanWagner

08-03-2012