This is the third post in a series on AD integration; the previous post deals with Active Directory installation and configuration
The Linux client I’ve chosen for the test lab is a 64-bit Fedora 10 installation. This distribution was chosen for its compatibility with my deployed systems. Like the Windows 2008 server, this machine is a VM, and the installation was a pretty generic GUI install. My deployed systems are installed via kickstart and managed with Puppet, but to maintain control over the environment, all test lab installation and configuration was done manually.
DHCP and DNS
Once the initial installation was done, I logged in as root and began to configure the system. Although most of my client systems are static IPs, I’ve decided to try using DHCP. The first configuration change I’ve made is to set the hostname in /etc/sysconfig/network, adding a line:
HOSTNAME=<client>
and to ask the system to send it’s hostname with DHCP requests in /etc/sysconfig/network-scripts/ifcfg-eth0:
DHCP_HOSTNAME=<client>
After setting both of these, I rebooted the system to have it pick up the new name. Once the system was back up, I logged in to verify it’s hostname, and checked on the DNS server to verify that it was registered in
Network Time Protocol
Kerberos requires clients to be reasonably closely synchronized to the server; NTP is the obvious choice for this function, as it’s enabled by default in Windows server, and can be set up on fedora clients with the following commands:
echo ’server <ad>’ > /etc/ntp.conf
chkconfig ntpd on
service ntpd start
Shortly after turning ntpd on, notifications should appear in /var/log/messages regarding the state of time synchronization.
In the test lab, I found that the NTP clients didn’t respond well to NTP synchronization; this is a known issue with VMware virtual machines, so I’ve disabled NTP and rely on VMware tools to keep the time sync’d.
OpenLDAP
OpenLDAP configuration is handled by /etc/ldap.conf, which so far has been the trickiest bit of configuration to figure out, so mention of a couple of troubleshooting steps is in order. First, I found it useful to install the openldap-clients package, which includes the ldapsearch utility that can be used for making arbitrary queries. Secondly, appending the line
debug 1
to /etc/ldap.conf provides a wealth of information that has been useful in troubleshooting connections — the output is sent to your terminal when using ‘finger’, ‘id’, or ‘getent’. Higher debug levels can be chosen, but for my purposes 1 was usually sufficient.
But back to /etc/ldap.conf; mine looks like this:
uri ldaps://<ad server>:636/base dc=fqdn,dc=comssl start_tlsssl ontls_cacertdir /etc/openldap/cacertsnss_initgroups_ignoreusers root,ldap,named,\avahi,haldaemon,dbus,radvd,tomcat,radiusd,\news,mailman,nscd,gdm,polkituser
nss_base_password ou=people,?subnss_base_shadow ou=people,?subnss_base_group ou=groups,?sub?&(objectCategory=group)(gidnumber=*)nss_map_objectclass posixAccount Usernss_map_objectclass shadowAccount Usernss_map_attribute uid sAMAccountNamenss_map_attribute homeDirectory unixHomeDirectorynss_map_attribute shadowLastChange pwdLastSetnss_map_objectclass posixGroup groupnss_map_attribute uniqueMember member#debug 1
The ‘nss_initgroups_ignoreusers’ line is quite important — without it, Fedora 10 will fail to boot properly into GUI mode. Note also the reference to /etc/openldap/cacerts — this directory needs to have a copy of the root certificate for your PKI, whether it’s internal or third-party.
Name Service Switch
Configuration of NSS is pretty straightforward; /etc/nsswitch.conf should have the passwd, shadow, and group lines modified:
passwd: files ldap
shadow: files ldap
group: files ldap
At this point, you should be able to list user accounts — try ‘getent passwd’ and look for your Active Directory accounts at the bottom of the list; if you don’t see them, then uncomment the debug directive in ldap.conf, and see if the additional info gives you any clues. ‘ldapsearch -x’ may also provide some clues.
Kerberos 5
Kerberos deals with realms, which are kerberos administrative regions, and domains, which are DNS domains. By convention, realms are referred to in uppercase,
/etc/krb5.conf:
[libdefaults]default_realm = FQDN.COMticket_lifetime = 24hforwardable = yes[realms]FQDN.COM = {kdc = <ad server>:88}[domain_realm]fqdn.com = FQDN.COM.fqdn = FQDN.COM[appdefaults]pam = {debug = falseticket_lifetime = 36000renew_lifetime = 36000forwardable = truekrb4_convert = false}
Pluggable Authentication Modules
/etc/pam.d/system-auth:
auth required pam_env.soauth sufficient pam_unix.so nullok try_first_passauth requisite pam_succeed_if.so uid >= 500 quietauth sufficient pam_krb5.so use_first_passauth required pam_deny.soaccount required pam_unix.so broken_shadowaccount sufficient pam_localuser.soaccount sufficient pam_succeed_if.so uid <>account [default=bad success=ok user_unknown=ignore] pam_krb5.soaccount required pam_permit.sopassword requisite pam_cracklib.so try_first_pass retry=3password sufficient pam_unix.so sha512 shadow \nullok try_first_pass use_authtokpassword sufficient pam_krb5.so use_authtokpassword required pam_deny.sosession optional pam_keyinit.so revokesession required pam_limits.sosession [success=1 default=ignore] pam_succeed_if.so \service in crond quiet use_uidsession required pam_unix.sosession optional pam_krb5.so
Once all of these changes have been made, Active Directory users should be able to authenticate on the new system. Since I use auto-mounted home directories, I don’t have PAM creating home directories for new users, but that’s not difficult to set up; look into the mkhomedir.so module if this sounds useful in your environment.
