howtos windows AD authentication
The first step in configuring Active Directory-based authentication for the Rocks cluster requires setting up the frontend/head node as if it were any other Red Hat Enterprise Linux or CentOS system. The second step is to configure 411-based file replication, and to join the compute nodes.
Note: These instructions require modifying some system files which are essential for login and name resolution purposes. I strongly suggest making backups of the original configuration files in case you need to restore default settings. While these settings work well for our system, I assume no responsibility for any problems or issues which may arise following use of these notes; they are provided merely for the sake of convenience.
I recommend also removing authconfig and nscd since these things may conflict with winbind. Personally, I disable SELinux too, but I understand that it's either required or desirable in certain settings, and so you may wish to leave it enabled instead.
1. Remove nscd and authconfig unless necessary for some reason or other:
[root@mycluster ~]# yum remove authconfig nscd
authconfig is harmless unless actively used to modify configuration information, in which case it will wipe out settings suggested below. nscd is largely incompatible with winbind and will result in undesirable behavior if it is allowed to run on the same system.
2. Edit /etc/hosts to map the hostname to the machines non-loopback address, such as:
127.0.0.1 localhost.localdomain localhost 10.1.1.1 mycluster.mydomain.org mycluster
3. Next, edit /etc/nsswitch.conf so that it resembles the text below -- be sure to make a copy of the original file as <code>/etc/nsswitch.conf.orig, just to be safe!
passwd: files winbind shadow: files winbind group: files winbind hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files publickey: nisplus automount: files aliases: files nisplus
4. Edit /etc/krb.conf as needed. The example is provided to give a very rough idea of what this file might look like on your system; I make no assertions that I have prepared this file properly, although something similar to this works well on our system:
MYDOMAIN.ORG MYDOMAIN.ORG mydomain.org MYDOMAIN.ORG mydomain.org admin server MYDOMAIN mydomain.org MYDOMAIN mydomain.org admin server
5. Edit /etc/krb5.conf as needed. A good place to start is chapter six of the Samba documentation.
Here's another sample file, in case it is helpful:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = MYDOMAIN.ORG
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.ORG = {
kdc = dc1.mydomain.org:88
kdc = dc2.mydomain.org:88
admin_server = dc1.MYDOMAIN.ORG:464
default_domain = MYDOMAIN.ORG
}
[domain_realm]
mydomain.org = MYDOMAIN.ORG
.MYDOMAIN.ORG = MYDOMAIN.ORG
mydomain = MYDOMAIN.ORG
.mydomain = MYDOMAIN.ORG
[pam]
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
6. Edit /etc/samba/smb.conf to include the necessary settings and desired options. It's my understanding that the idmap_rid syntax is deprecated, so there's probably a better way than what's described here. This works well for us. Here's an example, though your eventual configuration will likely differ from this one:
[global]
security = ads
workgroup = MYDOMAIN
netbios name = MYCLUSTER
realm = MYDOMAIN.ORG
allow trusted domains = no
idmap backend = idmap_rid:MYDOMAIN=10000-100000000
idmap uid = 10000-100000000
idmap gid = 10000-100000000
template shell = /bin/bash
template homedir = /export/home/%U
winbind use default domain = yes
winbind offline logon = yes
winbind enum users = yes
winbind enum groups = yes
winbind nested groups = yes
preserve case = yes
short preserve case = yes
case sensitive = no
encrypt passwords = yes
passdb backend = tdbsam
client use spnego = yes
domain master = no
7. It's necessary to edit the pam.d/system-auth file to include the necessary winbind bits. Be extremely careful when editing this file! Mistakes in editing PAM configuration files may result in an unusable system which requires single user mode to access. Make a copy of the original file, and save it as system-auth.orig in case you munge this file somehow and need to restore it. You've been warned!
Edit /etc/pam.d/system-auth to look something like:
#%PAM-1.0 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_winbind.so cached_login use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_krb5.so account [default=bad success=ok user_unknown=ignore] pam_winbind.so cached_login 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_winbind.so cached_login use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so silent session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session optional pam_mkhomedir.so skel=/etc/skel umask=0644 silent session required pam_unix.so session optional pam_krb5.so
8. Next, set the time server settings. Edit /etc/ntp.conf to look like:
server dc1.mydomain.org iburst server dc1.mydomain.org iburst server mytimeserver.mydomain.org driftfile /var/lib/ntp/drift
9. Finally, join the frontend to your Windows domain. Execute the following commands:
[root@mycluster ~]# service ntpd restart [root@mycluster ~]# net ads join -U <your ADS username> [root@mycluster ~]# chkconfig winbind on [root@mycluster ~]# service winbind restart
If the join succeeded, your Rocks frontend should be able to authenticate users via Active Directory! To be safe, perform a Kerberos test as well. Try to obtain a Kerberos ticket by using 'kinit' followed by your domain username. If a ticket can be obtained, destroy it with kdestroy and then proceed to attempt login via SSH. If SSH login with a domain username is successful, follow the next steps to join cluster compute nodes to the domain as well.
1. If you're unfamiliar with the 411 service used by the Rocks cluster, the following notes may be very helpful:
2. The second step is to verify that the samba-common RPM is available on the compute nodes. Just because a package is installed on the frontend by default (like samba-common), does not mean it's available on the compute hosts. Log via SSH from the frontend (a.k.a. tukey) into one of those hosts, say compute-0-0, and check to see if it's installed:
rpm -qa samba-common
If the prompt reappears and you don't see the package name and version appear, it's not installed.
If samba-common is not available, you will need to follow the Rocks instructions for adding a new package for those hosts via the extend-compute.xml Kickstart file and rebuild the nodes so that they include this package. Otherwise, you will be unable to join the compute nodes with winbind to the AD domain, and subsequently users will successfully authenticate to the frontend only to find that they cannot run any jobs on compute nodes.
3. Once those elements are working, edit the list of files 411 replicates on the compute nodes; this file is located on the frontend:
vim /var/411/Files.mk
Add the following lines to the end of the file:
FILES += /etc/nsswitch.conf FILES += /etc/krb.conf FILES += /etc/krb5.conf FILES += /etc/samba/smb.conf FILES += /etc/pam.d/system-auth FILES += /etc/ntp.conf
4. The next step is to make the 411 database; if all goes well, it will look something like this:
[root@mycluster ~]# cd /var/411 [root@mycluster 411]# make -C /var/411 make: Entering directory `/var/411' /opt/rocks/sbin/411put --comment="#" /etc/krb.conf 411 Wrote: /etc/411.d/etc.krb..conf Size: 871/464 bytes (encrypted/plain) Alert: sent on channel 255.255.255.255:8649 with master 192.168.0.1 /opt/rocks/sbin/411put --comment="#" /etc/krb5.conf 411 Wrote: /etc/411.d/etc.krb5..conf Size: 1961/1273 bytes (encrypted/plain) Alert: sent on channel 255.255.255.255:8649 with master 192.168.0.1 /opt/rocks/sbin/411put --comment="#" /etc/samba/smb.conf 411 Wrote: /etc/411.d/etc.samba.smb..conf Size: 1560/978 bytes (encrypted/plain) Alert: sent on channel 255.255.255.255:8649 with master 192.168.0.1 /opt/rocks/sbin/411put --comment="#" /etc/pam.d/system-auth 411 Wrote: /etc/411.d/etc.pam..d.system-auth Size: 2978/2029 bytes (encrypted/plain) Alert: sent on channel 255.255.255.255:8649 with master 192.168.0.1 /opt/rocks/sbin/411put --comment="#" /etc/ntp.conf 411 Wrote: /etc/411.d/etc.ntp..conf Size: 697/340 bytes (encrypted/plain) Alert: sent on channel 255.255.255.255:8649 with master 192.168.0.1 make: Leaving directory `/var/411'
5. Now 411 is aware of the appropriate configuration files; the next step is to replicate them. This generally happens on an hourly basis, but you can force the synchronization on all nodes with the following command:
[root@mycluster 411]# rocks run host compute '411get --all'
Be patient; there will be a slight pause, and if all is successful, you'll see the following reported for each node in the cluster:
Wrote: /etc/group Wrote: /etc/krb5.conf Wrote: /etc/nsswitch.conf Wrote: /etc/shadow Wrote: /etc/auto.smb Wrote: /etc/auto.misc Wrote: /etc/auto.master Wrote: /etc/passwd Wrote: /etc/samba/smb.conf Wrote: /etc/krb.conf Wrote: /etc/ntp.conf Wrote: /etc/auto.home Wrote: /etc/auto.net Wrote: /etc/pam.d/system-auth Wrote: /etc/auto.share
6. Proceed with joining the host to the AD domain, as with RHEL or CentOS:
service ntpd restart net ads join -U <your ADS username> chkconfig winbind on service winbind restart
Log in to the box (via SSH/XWindows) and test authentication. It's probably a good idea to test obtaining a Kerberos ticket by using 'kinit' followed by a domain username. If a ticket can be obtained, destroy it with kdestroy and then proceed to attempt login via SSH.
7. Comments
We tried the setup with a current Rocks 7 base and in general, the setup worked. The main issues were that we also had to adapt the /etc/pam.d/password-auth file.
One remaining issue is that with the current setup in smb.conf (template homedir = /export/home/%U) we get error messages when logging in to Compute nodes (cannot create dir in /export/home/<user></user>). So we changed the template homedir to /home/%U but of course, then the mkhomedir doesn't work anymore.
© 2014 www.rocksclusters.org. All Rights Reserved.