Full Integration of Active Directory
From AstroArch
Configure AD
You may need to set up AD authentication for ESX version 3 depending on the version of Winbind you are using. First configure your AD server if necessary; The latest versions of the Samba package do not require these changes.
Start->Administrative Tools->Domain Controller Security Policy
Security Settings->Local Policies->Security Options
Disable both:
Domain member: Digitally encrypt or sign secure channel data (always)
Microsoft network server: Digitally sign communications (always)
Note only make these changes if you are using Samba versions < 3.0.25. The default versions from VMware are quite out of date and require these changes. Most AD administrators will not be willing to make these changes.
Configure ESX
- Download krb5-workstation
- Install krb5-workstation in order to test your configuration
rpm -ivh krb5-workstation-1.2.7-61.i386.rpm
- Download the latest versions of Samba and pam_krb5 that will work with ESX to authenticate ESX using AD
- Upgrade pam_krb5-1.77-1 to pam_krb5-2.2.11-1
- Upgrade samba-client-3.0.9-1.3E.10vmw to samba-client-3.0.25-2
- Upgrade samba-common-3.0.9-1.3E.10vmw to samba-common-3.0.25-2
rpm -Uvh pam_krb5-2.2.11-1 samba-client-3.0.25-2 samba-common-3.0.25-2
- Configure the ESX Firewall (v3.5)
esxcfg-firewall -e activeDirectorKerberos esxcfg-firewall -e LDAP esxcfg-firewall -e kerberos
OR (v3.x)
esxcfg-firewall -e activeDirectorKerberos esxcfg-firewall -o 445,tcp,out,MicrosoftDS esxcfg-firewall -o 445,udp,out,MicrosoftDS esxcfg-firewall -o 389,tcp,out,LDAP esxcfg-firewall -o 464,udp,out,kpasswd esxcfg-firewall -o 464,tcp,out,kpasswd
- Enable AD authentication within ESX
esxcfg-auth --enablead --addomain=VMWARELAB.INTERNAL.COM --addc=w2k3-ad.vmwarelab.internal.com
- Now test the Kerberos connection:
/usr/kerberos/bin/kinit Administrator Password for Administrator@VMWARELAB.INTERNAL.COM: kinit(v5): Clock skew too great while getting initial credentials
- Fix any issues that appear from this command. Without krb5-workstation installed, the kinit command does not exist. In this case, the AD server’s time and the ESX Server’s time are too different, and one of them needs to be fixed. It is best for both servers to use the same time source. After the Kerberos problems have been solved, it’s time to set up the configuration files to talk to AD.
- In some cases, is necessary to specify the proper encryption types used by the AD server. The error that leads up to this is a report on incorrect enctypes. Update the /etc/krb5.conf file to be similar to the following, bold lines are additions.
# Autogenerated by esxcfg-auth
[domain_realm] vmwarelab.internal.com = VMWARELAB.INTERNAL.COM .vmwarelab.internal.com = VMWARELAB.INTERNAL.COM
[libdefaults] default_realm = VMWARELAB.INTERNAL.COM default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5 rc4-hmac default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5 rc4-hmac
[realms]
VMWARELAB.INTERNAL.COM = {
admin_server = w2k3-ad.vmwarelab.internal.com:464
default_domain = vmwarelab.internal.com
kdc = w2k3-ad.vmwarelab.internal.com:88
}
- It is possible to point the admin_server to just the domain, but be sure that this address resolves correctly in your DNS to the appropriate domain controller (s). Name resolution must work as appropriate.
- Modify /etc/pam.d/system-auth to integrate into AD, once more bold lines are additions or have been modified:
#%PAM-1.0 # Autogenerated by esxcfg-auth
account required /lib/security/$ISA/pam_unix.so broken_shadow account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_krb5.so account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_access.so
auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass minimun_uid=1000 auth required /lib/security/$ISA/pam_deny.so password required /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_krb5.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so session required /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel umask=0077
- Note the first pam_krb5.so line will allow account authentication if there is a local account without errors if the UID is < 1000, which implies no system accounts can be accessed via AD authentication. Also note the last line will create a home directory for the AD user automatically. A home directory is required when logging in to Linux-based systems such as ESX. Also, use this file as is, because the use_first_pass and use_authtok options are required; otherwise, you will be asked for passwords many, many times.
- The last line of the account section of the system-auth file references pam_access.so which allows the administrator to control who can login from which systems. An example of the /etc/security/access.conf file follows. This file allows root access from crond, console, ttys 1-6, IP Address 127.0.0.1 and not from anywhere else. It also allow allows those users in the vmadmins group (whether from a local group or AD) to gain access to the system from any IP except for the user badadmin who can gain access ONLY from the IP address of 192.168.1.100. All other access is denied. The manual page on access.conf (man access.conf) will give many more details on how to set this up. This is an important step else it may be possible for others to gain access to information they should not have, like the configuration of the virtual machines.
# Access.conf + : root : crond console tty1 tty2 tty3 tty3 tty5 tty6 + : root : 127.0.0.1 + : @vmadmins EXCEPT badadmin : ALL + : badadmin : 192.168.1.100 - : root : ALL - : ALL : ALL
- Modify /etc/samba/smb.conf should look like the following:
[global]
workgroup = VMWARELAB
server string = Samba Server
printcap name = /etc/printcap
load printers = yes
cups options = raw
log file = /var/log/samba/%m.log
max log size = 50
security = ads
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
dns proxy = no
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
template shell = /bin/bash
template homedir = /home/%D/%U
winbind use default domain = yes
password server = w2k3-ad.vmwarelab.internal.com
realm = VMWARELAB.INTERNAL.COM
- Of special importance is the workgroup and realm fields; these define the domain and Kerberos realm, respectively. The template lines also provide the location in which to create home directories. Because home directories are owned by the users themselves, they are created by the user so, special attention needs to be paid to permission on the template_homedir directory. Note the %D in the line, which refers to the domain to be used (in our case, VMWARELAB).
- Do not include any Shares in the file. Note that Samba will not be started, this setup is required for Winbind and the pam_mkhomdir module. However, leaving out shares will help if samba is accidently started.
- The final requirements for Winbind and pam_mkhomedir follow:
mkdir /home/VMWARELAB chmod 1777 /home/VMWARELAB mkdir /var/log/samba
- Modify /etc/nsswitch.conf as follows, note the addition of winbind on the appropriate lines:
# Autogenerated by esxcfg-auth
aliases: files nisplus automount: files nisplus bootparams: nisplus [NOTFOUND=return] files ethers: files group: files winbind hosts: files dns netgroup: nisplus netmasks: files networks: files passwd: files winbind protocols: files publickey: nisplus rpc: files services: files shadow: files winbind
- Join the machine to the domain and enable Winbind and ensure that Winbind runs on reboot:
net ads join -UAdministrator Administrator's password: Using short domain name -- VMWARELAB Joined 'AURORA01' to realm 'VMWARELAB.INTERNAL.COM' service winbind start chkconfg winbind on
- Verify that the groups are resolved for an individual user:
wbinfo -g domain computers domain controllers schema admins enterprise admins domain admins domain users domain guests group policy creator owners
- Verify that Users are resolved:
wbinfo -u administrator guest support_388945a0 krbtgt testauser smbservice
- Verify that trusted secret via RPC calls succeed
wbinfo -t
- Verify ESX sees the AD groups
getent group root:x:0:root ... domain computers:*:16777220: domain controllers:*:16777218: schema admins:*:16777222:administrator enterprise admins:*:16777223:administrator domain admins:*:16777219:administrator domain users:*:16777216: domain guests:*:16777217: group policy creator owners:*:16777224:administrator
- Verify ESX sees the AD Users
getent passwd root:x:0:0:root:/root:/bin/bash ... administrator:*:16777216:16777216:Administrator:/home/VMWARELAB/administrator:/bin/bash guest:*:16777217:16777217:Guest:/home/VMWARELAB/guest:/bin/bash ... krbtgt:*:16777220:16777216:krbtgt:/home/VMWARELAB/krbtgt:/bin/bash
- Verify an AD user picks up proper UID,GID, and groups.
id testauser uid=16777221(testauser) gid=16777216(domain users) groups=16777216(domain users)
