Woot! With the help of barthag, I got one of our linux boxes configured to provide passwd file map backend via AD/LDAP and authentication via AD/Kerberos. Most of the problems stem from permissions issues on the AD side and making sure things are open “enough” to let us through to query for information.
On the Linux side (specifically, Red Hat Enterprise Linux 5 Update 2), there are four files you have to touch to make this work: /etc/krb5.conf, /etc/ldap.conf, /etc/nsswitch.conf, and /etc/pam.d/system-auth.
In our configuration, I’m using LDAP to provide the transport for the actual directory information lookups and Kerberos to manage the authenticating of users to the system. It’s an easy enough configuration for this. For testing, we’re not encrypting the LDAP connection because we haven’t yet figured out the correcting pathing and formats of the various certificate files necessary for nss_ldap to work correctly (yay underdocumented features!). Plus, since my test box is close to the AD servers network-wise, I know the connection is secure enough. Production usage of this config will very likely enforce the use of SSL since we’d be providing these configs for people outside of our local ITS network (but still on-campus).
Also, for this initial test, we’re only working with the passwd map.
So, without further adieu.
/etc/nsswitch.conf
passwd: files ldap shadow: files ldap
/etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = AUSTIN.UTEXAS.EDU
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
AUSTIN.UTEXAS.EDU = {
kdc = austin.utexas.edu:88
admin_server = austin.utexas.edu:749
default_domain = austin.utexas.edu
}
[domain_realm]
.austin.utexas.edu = AUSTIN.UTEXAS.EDU
austin.utexas.edu = AUSTIN.UTEXAS.EDU
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
/etc/ldap.conf
### ### ldap config for binding to AD with a read-only bind account over ### cleartext. ### base dc=austin,dc=utexas,dc=edu uri ldap://austin.utexas.edu/ binddn thebinduser bindpw thebindpasswd scope sub timelimit 120 bind_timelimit 120 idle_timelimit 3600 nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm # limit to the Austinites->People OU that have a uid set. nss_base_passwd ou=Austinites,ou=People,?sub?&(objectCategory=user)(uid=*) #nss_base_group ou=Group,dc=example,dc=com?one #nss_base_hosts ou=Hosts,dc=example,dc=com?one #nss_base_services ou=Services,dc=example,dc=com?one #nss_base_networks ou=Networks,dc=example,dc=com?one #nss_base_protocols ou=Protocols,dc=example,dc=com?one #nss_base_rpc ou=Rpc,dc=example,dc=com?one #nss_base_ethers ou=Ethers,dc=example,dc=com?one #nss_base_netmasks ou=Networks,dc=example,dc=com?ne #nss_base_bootparams ou=Ethers,dc=example,dc=com?one #nss_base_aliases ou=Aliases,dc=example,dc=com?one #nss_base_netgroup ou=Netgroup,dc=example,dc=com?one nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_attribute uid sAMAccountName nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute shadowLastChange pwdLastSet nss_map_objectclass posixGroup group nss_map_attribute uniqueMember member pam_login_attribute sAMAccountName pam_filter objectclass=User pam_password ad pam_password_prohibit_message "Sorry, you must change your password using the UTDirect EID interface." # we don't use referrals at UT. referrals no # return more than 10 thousand entries when iterating over the entire # map. nss_paged_results yes page_size 1000
/etc/pam.d/system-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 sufficient pam_krb5.so auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account sufficient pam_unix.so account sufficient pam_krb5.so account sufficient pam_succeed_if.so uid < 500 quiet 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 required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
Great. So with this configuration, I can verify that I can login to the Linux box via ssh using my Windows username and do things as myself. There are some caveats to this: you must be in the Austinites OU at this point AND you must have the appropriate posixAccount attributes populated. At a minimum, that’s uidNumber, gidNumber, loginShell, unixHomeDirectory, and uid. You may have noticed that we’re actually using sAMAccountName for the login name above. We’re still playing with that. We might use uid instead because that’s something we can more easily filter on to limit on for different pieces of the account lookups.
So, what’s next?
- need to beat on the system and make sure no one WITHOUT the attributes set can login.
- need to work on the group map and get that working since we’re currently only doing passwd file lookups.
- this includes understanding how to deal with secondary groups.
- need to work on the netgroup map and come up with a standardized way of handling that so we can (under Linux), configure people in the /etc/security/access.conf for access restrictions.
- need to figure out if there are other access restriction mechanisms we need to pay attention to.
- need to look at all the pam configs on a default box and see if there’s something that isn’t covered by the system-auth template.
- need to figure out just how far into Kerberos we want to go. What we’re doing now is good for authenticating a single session. Need to determine if we want to go to single sign-on or not and do all the extra bits associated with using kerberos.
- need to figure out if we should do authentication using LDAP only (honestly, I’d prefer not to, but that depends on what others in the group need).
- need to get this setup on a Solaris 10 system for testing.
- need to address the issue of a person’s loginShell and coming up with some standards for those, in order to deal with departments that have differing shell policies but with overlapping accounts (e.g., researcher that has accounts in two Unix areas but that have differing policies on where or which shells should be used).
- need to address the issue of a person’s unixHomeDirectory possibly differing between two Unix areas. Same issue as above, but stickier because it’s generally a lot harder to consolidate this down to a consistent path name than it is to consolidate shells down to a consistent path name.
There are problably others, but these are my known unknowns at this point.
Things that were referenced to make all this work:
- http://blog.scottlowe.org/2008/04/11/ad-integration-tip-dealing-with-more-than-1000-users/
- http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/
