Following on from my last post about kickstart scripts which looked at partitioning, this one concentrates on user account provisioning. There are lots of useful guides online about how to configure user accounts, however none that fitted all my requirements. So nothing below is groundbreakingly new, but it does demonstrate a complete working solution.
I had 2 basic requirements that I wanted to implement:
- AD integration for passwords
Although the thought of making the ESX hosts reliant on a Microsoft technology gives me the “willies“, it is the de facto authentication method in most enterprises. As I didn’t want everyone logging in under the one account, password management for multiple accounts quickly becomes impossible when you have more than a handful of host servers. AD integration means you can offload the burden of maintaining local passwords.
- Use of sudo
In my experience, it has become quiet common for companies to create a single root password across all their ESX servers and share this amongst the administrators. These days no-one would create a single Domain Admins account for their Windows computers and share this around their staff, encouraging everyone to log in with it.
There are several approaches to reducing the (obvious) risk that this creates. For example, VMware disables root access via SSH as a default, but this is usually the first thing most people enable once the install is finished. I don’t purport to be any sort of security expert, and I certainly don’t think my solution below is the most secure possible, but I do consider it a sensible medium of security versus convenience. We all know that if its anything more than a mild nuisance, then we’ll just break it open.
How to implement this in a kickstart script
I will explain each part of the script, but it is worth noting that all the commands can be run on the Service Console, or from a shell script, if you want to retroactively fit this sort of user model to an existing server. It was tested to run on ESX 4 servers, but should run fine against ESX 3.x hosts.
%post –interpreter=bash
# Enable AD Authentication
/usr/sbin/esxcfg-auth –enablead –addomain=[DOMAIN] –addc=[DOMAIN]
This allows the local accounts to authenticate against your AD domain. I found the –addc option would run fine if I just specified the domain instead of hard coding it to an individual DC. There are several additional switches available for kerberos authentication, however I found that in my test environment I didn’t need to stipulate them. Your mileage will undoubtedly vary, depending on your AD mode and setup . There are some excellent guides out there, if you need to add this in.
# Give new accounts the path variables to run esxcfg commands
sed -e “s/PATH=\$PATH:\$HOME\/bin/PATH=\$PATH:\/usr\/local\/sbin:\/sbin:\/usr\/sbin:\$HOME\/bin/g” /etc/skel/.bash_profile > /etc/skel/.bash_profile.new
mv -f /etc/skel/.bash_profile.new /etc/skel/.bash_profile
This adds in all the normal root path variables to new user accounts, so when using sudo you don’t need to specify the whole path. This is one of those things that isn’t strictly necessary, but without makes using sudo such a pain for the uninitiated that users get fed up with “change”.
# Help identify when logged in as root
echo “PS1=’\[\e[31m\]\u@\h:\w#\[\e[m\]‘” >> /root/.bashrc
echo “PS1=’\[\e[32m\]\u@\h:\w#\[\e[m\]‘” >> /etc/skel/.bashrc
Again another nicety that I like to add in. It just helps to highlight when you are “su”ing or logging in as root.
# Add enterprise Groups and Users
/usr/sbin/groupadd -g 5000 esxadmin
/usr/sbin/useradd -u 501 -G esxadmin tom -m
/usr/sbin/useradd -u 502 -G esxadmin dick -m
/usr/sbin/useradd -u 503 -G esxadmin harry -m# Add local users needing admin access
# /usr/sbin/useradd -u 601 -G esxadmin [LOCAL_USER1] -m
# /usr/sbin/useradd -u 602 -G esxadmin [LOCAL_USER2] -m
Firstly, this creates a group called “esxadmin”. It then creates local accounts for 3 users: tom, dick and harry and adds them to the group. The second section is commented out, but allows for additional accounts to be added. My thinking here is that in a largish enterprise environment there will always be some users that need to log into all ESX servers – your “domain admins” of the ESX world if you like. You would leave their names in the script for all your servers. However, you’re likely to have some administrators that are specific to just a few local servers, so these would be added in on a per server basis. The usernames used here have to match their AD usernames.
# Add esxadmin to sudoers
echo #
echo “# Allow esxadmin group to sudo” >> /etc/sudoers
echo %esxadmin ALL = \(ALL\) ALL >> /etc/sudoers
This allows all members of the esxadmin group to run commands using sudo with effectively the elevated privileges of root.
# Allow ROOT access using SSH
sed -e ‘s/PermitRootLogin no/PermitRootLogin yes/’ /etc/ssh/sshd_config > /etc/ssh/sshd_config.new
mv -f /etc/ssh/sshd_config.new /etc/ssh/sshd_config
service sshd restart
Now this section is a little controversial 
. Why go to all this trouble and then allow root access via SSH. Well I have included it for completeness, as its a common request. There is a good reason that you may choose to include it though. If the service console cannot connect to a DC for whatever reason (networking problem, DC is offline, vswif0 is screwed,…), then you won’t be able to log in with one of your local esxadmin accounts. Imagine your whole environment is virtualised including all DCs and you start to see the chicken and egg possibilities. However, you can always log in with the root password. So this isn’t an issue if all your hosts are in the server room next door, you have an iLO/RSA/DRAC card in them all, or have remote access to the console KVM. If you don’t, then you might want to leave this in.
# Enable the SSH client (Out/From an ESX hosts)
/usr/sbin/esxcfg-firewall -e sshClient
This just let’s you bounce from one server to the next. Effectively saves you having 8 different putty sessions open on your desktop at once. It also allows you to do thinks like SCP files across to another host.
# Enable TCP outgoing kerberos, there are issues with udp and enable blockOutgoing
/usr/sbin/esxcfg-firewall –openport 88,tcp,out,KerberosClientTCP
/usr/sbin/esxcfg-firewall –openport 53,tcp,out,dns
/usr/sbin/esxcfg-firewall –blockOutgoing
Lots of people warned that the above was needed to get around some issues with the AD authentication. I’m not sure if this has been fixed since then, and haven’t had a chance to test it myself, so I’ve included it here.
# Remove dangerous default of ctrl-alt-del from inittab
sed -e ‘s/ca::ctrlaltdel/# ca::ctrlaltdel yes/’ /etc/inittab > /etc/inittab.new
mv -f /etc/inittab.new /etc/inittab
This snippet fixes this issue. I’ve been told that this default is going to be changed in an upcoming patch, but until then this removes the threat.
# SSH Legal Message…
echo >> /etc/banner
echo ************************************************************************* >> /etc/banner
echo * Legal banner if required * >> /etc/banner
echo ************************************************************************* >> /etc/banner
echo >> /etc/banner
echo Banner /etc/banner >> /etc/ssh/sshd_config
If you need a message displayed on the console when a user logs in, then this takes care of it.
# Create post config script
cat << \EOF > /etc/rc3.d/S99postconf
#!/bin/bash# Allow hostd etc. some time to load
/bin/sleep 90# Grant the group named esxadmin admin permission to ha-folder-root
/usr/bin/vmware-vim-cmd vimsvc/auth/entity_permission_add vim.Folder:ha-folder-root esxadmin true Admin true# Reset system to normal boot mode
echo “Removing automated post script.”
rm /etc/rc3.d/S99postconf
EOF
chmod +x /etc/rc3.d/S99postconf
This last section runs after the first reboot and gives the local esxadmin group “Administrator” privileges. This allows the local accounts in the esxadmin group to log into the host directly with the vSphere GUI client.
What’s the end result?
Once all these steps are implemented, the users tom, dick and harry can log into their ESX server using their regular AD accounts and passwords. They will be able to run commands that normally need root privileges using sudo, all without having to know the root password. All the commands will be logged against their own user accounts so everything is now auditable and bit more SOX compliant.
