I was recently working with Horizon View and VMware Identity Manager in a lab environment. To recreate a specific issue, I needed to enable two-factor authentication. I found a great article describing how to setup RADIUS with Google Authenticator to make this happen (https://blogs.vmware.com/consulting/files/2015/02/VMW_15Q1_TD_Horizon-View-Google-Authenticator_021715_FINAL_EMonjoin.pdf). Unfortunately I ran into a few issues, most likely because I was trying to use a newer version of Ubuntu. I wanted to document the updated steps in case I need to recreate this configuration in the future.
To start, I deployed an Ubuntu 16.04.1 template and joined it to Active Directory. For those steps, you can check out this post: http://enterpriseadmins.org/blog/virtualization/lab-template-ubuntu-16-04/.
VM in hand, and joined to Active Directory, I installed the RADIUS and Google Authenticator modules:
apt-get install libpam-google-authenticator freeradius -y
I then changed the radiusd.conf file to all the user and group to be root for this process. This is needed as Google Authenticator requires the .google_authenticator file created later to only be readable by the user. Running this process as root allows the radius process to read these files as well.
nano /etc/freeradius/radiusd.conf
Find the lines that state user=freerad and group=freerad. Update each to look like:
user=root group=root
We now update the users authorized to use Free RADIUS. We reject requests from users in a specific group, and then tell FreeRADIUS to use PAM for all other authentications. We do this by removing some comments, and adding a line in the freeradius/users file:
nano /etc/freeradius/users DEFAULT Group == "lab_radius_disabled", Auth-Type := Reject Reply-Message = "Your account has been disabled." DEFAULT Auth-Type := PAM
We now need to update a file to enable pluggable authentication modules in free RADIUS. Note: to find text using nano, you can use CTRL+W.
nano /etc/freeradius/sites-enabled/default
When we find the text for #PAM, remove the pound sign to enable PAM.
The default PAM RADIUS config only expects a password. Since we want to use our Google Auth code, we need to make a few changes.
nano /etc/pam.d/radiusd
Comment out the @include lines in the file, then add the following text:
auth requisite pam_google_authenticator.so forward_pass account required pam_unix.so use_first_pass
Now we need to define which clients can use our RADIUS server, and what their ‘secret’ will be. It is common to restrict this so only specific hosts can access RADIUS, and each server can have a unique secret. However, for my lab, I’m going to allow all servers to connect to RADIUS using the same secret. We do this by editing this file:
nano /etc/freeradius/clients.conf
And adding a client entry like this one:
client 192.168.0.0/16 {
secret = s3cur3.rad
shortname = PrimaryLabSubnet
}
Note – alphanumeric and _-+. (underscore hyphen plus period) are the supported characters for this secret (from https://support.software.dell.com/kb/154463
Now that we have all of the configuration files edited, we can restart the freeradius service:
service freeradius restart
You are almost there…
Users will need to login (SSH) to our RADIUS server to generate their specific Google Authenticator key. This only needs to happen once (unless they need to regenerate their unique key). By default, a user can just enter ‘google-authenticator’, answer half a dozen questions, and will get a QR code for their unique key.
To ensure that each user answers these questions the same, lets pre-answer them… by creating an alias for all new users. To save a few characters, we’ll shorten this alias to google-auth.
nano /etc/skel/.bashrc
Now we scroll down to where the other aliases are and add one of our own:
alias google-auth='google-authenticator -tdf -l "$USER Home Lab" -r 3 -R 30 -w 17 -Q ANSI'
This file will automatically be copied to the .bashrc folder for all newly created profiles. If you’ve already logged into your Linux box and want this handy alias, you can edit your personal /home/username/.bashrc file, or just copy the default .bashrc for new users into your profile, like this:
cp /etc/skel/.bashrc /home/bwuchner/.bashrc
Option #1, new users
The first time a user logs in, they will need to create a unique key for their account. To do this, they simply type
google-auth
and lanuch the quick alias we just made. This will generate a QR code they can use to add the account to their mobile device.
Option #2, existing users
I have several labs, each with their own RADIUS servers. Instead of having a unique key per lab, I re-use my Google Authenticator key across environments — don’t tell my info-security team 🙂
To do this, I just need to copy the contents of /home/bwuchner/.google_authenticator to other RADIUS servers. Since this file only contains simple text, I pass it into a text editor over SSH.
nano .google_authenticator
We add our key text, which looks like this:
A2ANXSELX3KIS5DD "RATE_LIMIT 3 30 " WINDOW_SIZE 17 " DISALLOW_REUSE " TOTP_AUTH 52311114 79666855 35676886 84689191 97921843
Note: In the real world you’d like to be much more security conscious of this text, as it represents the ‘something you have’ factor of authentication. Anyone who knows this text can easily impersonate you.
The file must be readable only by the current user, so change permissions with:
chmod 400 ~/.google_authenticator
Thats it! We can now test that everything is working using radtest. Here is simple syntax, assuming my username is bwuchner, password is P@ssw0rd, RADIUS server is 192.168.0.100 and RADIUS secret is s3cur3.rad:
radtest bwuchner 'P@ssw0rd442287' 192.168.0.100 1812 s3cur3.rad
The response should show Access-Accept. If you get something else, like Access-Reject, then check /var/log/auth.log to see what went wrong. I find that it is easiest to have two SSH sessions opened — one running radtest and the other running
tail -f /var/log/auth.log
Good luck, I hope this helps make your lab authentications more secure!
