Setting CentOS / Redhat to use Active Directory for Authentication Only

I was recently faced with a situation where I was establishing a lone Linux server in a Windows native environment.  A small set of users would be using this server infrequently but we wanted to make sign on convenient and traceable. What we did is set the server to pass authentication back to the domain controllers. The local user list is then edited with those domain user IDs we wish to have access to the system.

For this example lets assume the following:

Domain:  contoso.com 

Domain controllers: dc1, dc2,dc3

Time Server:  time.contoso.com

Test user account:  atest@contoso.com

Sync Time with the Domain:

Be sure the system clock is  syning with domain with the following crontab entry:

0 0 * * * rdate –s time.contoso.com

Kerberos Configuration:

Replace the contents of /etc/krb5.conf with the following (capitalization does matter):

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

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

[realms]
CONTOSO.COM = {
  default_domain = contoso.com
  kdc = DC1.CONTOSO.COM
  kdc = DC2.CONTOSO.COM
  kdc = DC3.CONTOSO.COM

  admin_server = DC1.CONTOSO.COM
}

[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM

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

The last “validate=false” command ensures that TGT validation (which may not be supported at Contoso) is not used, it will cause authentication failure.

Test with kinit:

# kinit atest@CONTOSO.COM

# klist     (to see if a ticket was created)

Enable Kerberos:

Use the system-config-authentication GUI to enable Kerberos user authentication.

Click OK

Change system-auth:

Setup /etc/pam.d/system-auth to use Kerberos authentication first then unix authentication by setting up the auth section like this:

auth        required      pam_env.so
auth        sufficient      pam_krb5.so     nullok try_first_pass
auth        sufficient    pam_unix.so       nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

Fix local su access:

Setup /etc/pam.d/su to use pam_unix as the first choice so su to root doesn’t trigger a bad auth request against Kerberos

auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth           required        pam_wheel.so use_uid
auth            sufficient      pam_unix.so try_first_pass
auth            include         system-auth
account         sufficient      pam_succeed_if.so uid = 0 use_uid quiet
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         optional        pam_xauth.so

STOP HERE if you only want to ‘authenticate’ again AD. You can simply place the user in passwd (using useradd or other scripts) and they will have access. Using the conventional linux user management tools along with ‘Kerberos only’ authentication may allow you to customize the home directory and track group IDs easier than full AD integration using winbind.