Build Your Own Two Factor Authentication Server

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 ( 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:

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:


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 forward_pass
account required 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 {
        secret          = s3cur3.rad
        shortname       = PrimaryLabSubnet

Note –  alphanumeric and _-+.  (underscore hyphen plus period) are the supported characters for this secret (from

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


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:


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 and RADIUS secret is s3cur3.rad:

radtest bwuchner 'P@ssw0rd442287' 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!

One comment

  1. Yasin KAPLAN says:

    You can examine for a Windows based implementation for Google Authenticator with RADIUS.

Leave a Reply

Your email address will not be published. Required fields are marked *


Notify me of followup comments via e-mail. You can also subscribe without commenting.