I decided to write this post to set out, in one place, a complete explanation of:
• The components you need for a complete two-factor authentication system, using Yubikeys
• How the components work together
• How to set the components up in a Windows Domain Environment.
When I went to set up to secure my workplace’s Windows domain, I looked for a document that would tell me how to do this, and couldn’t find one.
I hope this post will help others wanting to know how the Yubikey fits into a complete system, and how to set up a working system in your own workplace.
Because it is so long, I wanted to upload the content of this post as a Word Document or PDF as well. Unfortunately this board won't let me
ENVIRONMENTI manage a small Windows Domain environment. We are running Small Business Server 2008, however I expect this guide will work for any Windows Active Directory Environment (post Windows NT anyway). We have about 30 users who log on to the domain via Windows PCs on our LAN.
We have remote users who log onto my system via Remote Web Workplace from PCs over which I have no control. The users, after connecting to Remote Web Workplace, log onto a Terminal Server machine (which presents as a PC) which then gives them internal LAN access. This terminal server PC is a virtual machine, running on a VMWARE ESX server. The solution would work equally well with a normal PC, although this will only allow one login at a time.
We purchased the Yubikeys mainly so that we can issue them to our staff who connect to the office remotely, so that we can be better assured that the person logging in to our system is actually the person they claim to be – they must have BOTH the correct credentials, and the Yubikey device.
As I do not have control over the PC being used by the remote worker, I wanted a solution where no changes were required to that remote PC, and all the implementation was done inside our LAN. Because of this, the solution described would work just as well if you want to set up a system where the LAN users are issued with a Yubikey and are required to use it for authentication at logon inside the LAN.
OVERVIEWFirstly, an overview of the solution. This was actually the hardest part (for me) to figure out. Once I had a clear idea of how the solution would work, it became much easier to work out the pieces required, and the steps to take.
All of the components mentioned here are available free, either directly from Yubico, or linked from their site. The only things you have to buy are the Yubikeys.You need three main pieces:
• You need a Yubikey for each user you will be having log on to the PC(s) you will be setting up to use two-factor authentication – the Key;
• Your user needs to be presented with a logon that will actually accept the One Time Password (sorry, but I am going to use ‘OTP’ for ‘One Time Password’ from now on) generated by the Yubikey – the Client User Interface Component;
• That logon needs to authenticate the OTP, and confirm (or reject) the logon attempt -The Validation Server component.
Buying some Yubikeys is where you would tend to start. You can’t finish setup without them, although you can do quite a lot of preliminary work while waiting for them to arrive.
The second piece of the puzzle is achieved by installing pGina onto the PCs you want to use with two factor authentication. pGina is an open source software which puts a new login screen in front of the user. You also install another file that works with pGina, and which sends login checks from the PC to your authentication server.
The third piece is achieved by downloading and running the RADIUS_on_Premise server machine. This is a virtual machine which you run on a VMWARE ESX server. (If you don’t have an ESX Server there is other software made available from the Yubico site which you can install directly into one of your existing physical servers – I have not tried any of these. By inserting the authentication server as a virtual machine on your LAN, you can add this service to your network without having to worry about installing possibly incompatible software onto your current mission critical servers.)
DETAIL
SERVER SETUP (Validation Server)
It makes more sense to set up the authentication server first, before you set up the client that is going to authenticate to it. So I will start with the RADIUS_on_Premises II server virtual machine (which I am going to abbreviate to ROPII).
RADIUS stands for “Remote Authentication Dial In User Service”. A RADIUS server talks to your Active Directory server (in my case, the Small Business Server 2008) and gets the list of valid users of the system – this is the same list your AD server uses – and can passthrough password details to the AD Server for checking. ROPII is a RADIUS server.
The ROPII does more than this though. You give the ROPII server the list of your Yubikeys, and tell it to whom you have assigned each Yubikey. The ROPII links this with your list of users from your AD server. The ROPII also knows how to test the password generated by the Yubikey to see if it is genuine.
So, when set up, the ROPII knows the usernames who are allowed to log into the Domain, what Yubikey they are supposed to have, and can check the validity of the password put in by the user including the Yubikey OTP. (The password the user will enter is now going to need to include the OTP from that user’s Yubikey, because we are setting the PC up to do this in the Client Setup (our next step)). If any of the username, password, OTP, or even the particular Yubikey being used are not correct, the ROPII will deny the user the right to log on. Only if all is correct can the user proceed to gain access to the system.
You can download the ROPII from the Yubico website, here:
http://www.yubico.com/yubico-radiusYou should also download the configuration documentation from the same page.
Now there are some things that you should know that were not readily apparent from the info in the documentation that comes with the ROPII server:
• You cannot put the downloaded ROPII server straight onto your ESX server and boot it up. You have to first convert the image. Fortunately you can do this by using the free Standalone VM Converter available to download from VMWARE. You can get it here:
http://downloads.vmware.com/d/info/datacenter_downloads/vmware_vcenter_converter_standalone/4_0?rls=com.microsoft:en-au:IE-Address&q=vmware%20converter%20download&oq=vmware%20converter&aq=1&aqi=g10&aql=&gs_sm=e&gs_upl=767251l770529l0l16l13l0l4l4l0l351l2050l1.3.2.3• Once you have converted the machine, you can boot it up and start configuring. I recommend giving it a static ip, or at least a reservation in your DHCP server. You should configure it from the web interface (which means you need to know it’s ip, hence the recommendation for an IP reservation).
• Follow the documentation from Yubico about setting it up (the good stuff starts on page 9) – but note the following:
o The example in the documentation is to add “ROP.COM”. You are much more likely to have a domain with a ‘.LOCAL’ extension as your internal domain. So if your business is “MYBUSINESS” you probably have website: “MYBUSINESS.COM”, but your users probably log onto a domain called “MYBUSINESS.LOCAL”. Check your active directory server if you are not sure what you are using.
o The real trouble starts at page 15, the “Import Users”. It seems that the LDAP integration in this server is less than perfect. After MUCH experimentation, I was only able to get one configuration to work:
I had to use a Base DN where the top level was ‘CN=Users’. So, continuing with my example above, the Base DN to use would be: CN=Users,DC=MYBUSINESS,DC=LOCAL
• “But what if my users aren’t in that branch of Active Directory?” I hear you cry. Mine weren’t, and this had me stumped for ages. I tried everything I could think of to get the ROPII to import the users from the Base DN in which the Users were actually located. Frustratingly, the ROPII would happily report a successful import, then present me with an empty list of users. In the end, as a workaround, I resolved the issue from the Windows Server side, and MOVED the users I need to give Yubikeys to into the CN=Users. This is easy to do on the Windows Server, using “Active Directory, Users and Computers” admin tool. Right click the user, select “Move” and move it to the CN=Users. This is a default CN, and, if you are lucky, your users may already be in it. I found no ill effects on my network by moving my users into this CN.**
EDIT: Yes I did - It just took me a few days to realise - It removed these users from some Group Policy settings I had applied to their original branch of LDAP. If you move the users, you need to ensure you apply the requisite group policy to the new container! (It will be REALLY good when this issue is fixed in ROPII and we don't need to move the users!) As soon as I moved my users in there, and told the ROPII server this was my Base DN, it happily imported them.
you cannot import users from more than one level . Attempts to do so report a ‘success’ message, but unfortunately, again, you end up with an empty user list.
And, in case you think I didn’t try hard enough, you can’t manually enter the users in the ROPII server. The ROPII server presents you with the option of doing it, but refused my every attempt to actually do it.
This is clearly a glitch in this implementation, which hopefully will be resolved soon.
CONFIGURE YOUR YUBIKEYS• Now you have to pause in your configuration of your ROPII server, because your next step is to configure your Yubikeys, and import them into your ROPII server. (This is not required if you leave the OTP authentication to the Yubico servers. I thought taking the option of using the Yubico servers was a bit counterproductive, as the user would not be able to authenticate without an active internet connection, and anyway, I wanted the whole authentication to be in-house.)
• To configure your Yubikeys, you can use the personalisation tool, which you can get from here:
http://www.yubico.com/personalization-tool Make sure you get the User Guide from the same page.
• I used the ‘cross platform personalisation tool for Windows’
• There’s also a batch version on that page if you have lots of Yubikeys, and a few USB hubs, and want to do LOTS at a time. I did 10 using the normal tool and two USB slots and it only took a minute or so.
• For our purposes, in the personalisation Tool, you need to select “Program the Yubikey to create a dynamic Yubikey Configuration (OTP Mode)” . This is the third option from the top.
•
BUT WAIT – FIRST, select the second from last option: “Global Settings – Review or Change Settings”. (If you don’t do this now, you will just have to reprogram your Yubikeys all over again..
o In the Global Config, ensure that, under “Programming Options” you select the two options: ‘Ask for log output file name if not set’, and ‘Include Secrets in output file’.
o You need this log file, with this information in it, to upload to your ROPII server, which is patiently waiting for you to get back to it with this Yubikey information.
• Now that you have told the program to log your output, go ahead and reprogram all your yubikeys. You can review the user guide and set as you wish, but you don’t really need either a public or private identity. I used:
o a public entity, using the ‘single rand’ button to randomise the entity, and the ‘increment by one’ option,
o no private identity, and
o “randomise” for the key generation, and
o ‘send ENTER as the last keystroke’ (this is so that, when the button is pressed, the login dialog is dismissed automatically. If you don’t want this, leave this out)
o ‘Config unprotected, and leave it that way’ (a user can’t read from the config, and if they rewrite it they will just cut off their access to your system, without otherwise damaging it), and finally
o ‘Batch (multiple) mode’ (lets you do all your keys at once, quickly), and
o ‘Write to configuration 1’.
If you write to config 1, then you can’t authenticate with the Yubico servers anymore, but you can reconfigure config 2 to authenticate to the Yubico servers if you decide you need to (to post to the forums, for example).
You could just leave config 1 alone, and write to config 2, which means that the key can authenticate using your system (using config 2) or Yubico’s (using config 1 which is already programmed in).
The problem is, to use config one, the user just has to touch the ‘button’ on the Yubikey, while to use config 2 they have to hold it for approx 4 seconds (but not longer than 5). If they just touch the button, the key will emit the config 1 OTP, which will NOT work in your ROPII server.
I figured it will be easier on my users (and therefore myself) if I put the config the users have to use all the time into Config 1, and re-set up the Yubico compatible config into Config 2 just for those keys and those users who need to post to Yubico’s forums (ie, me!)
• When you start the configuration process, provided you have set the Global Config setting as above, the program will stop and ask you where to put the log file, then proceed to record in the log file all of the settings it is saving to the keys. (This has to be done at the time it writes to the keys, as the keys, once written, cannot have information read out of them.) Once you have finished, copy that log file. You need it to finish setting up the ROPII. Bring your pack of freshly set up Yubikeys with you too.
BACK TO YOUR ROPII WEB CONFIG TO COMPLETE SERVER SETUP• Log back in to your ROPII web config, click on your domain name, and click the “Yubikeys Import” tab. Then, browse to the log file you created when setting up your Yubikeys, and upload the file.
• Now at this stage, I allocated a Yubikey to each user.
o You do this by going to the user list tab, and click the “Assign a new Yubikey” link.
o Select a Yubikey from your pile of unallocated Yubikeys.
o Note the serial number printed on the key. These keys are otherwise identical, so it helps if you note the serial number down, and to whom you allocate it, so that you can give the right key to the right user. A key allocated to User A WILL NOT WORK for User B!
o Enter the user logon name (the ROPII should insert this for you if you select the user checkbox prior to clicking the “Assign a new Yubikey” link, but it did not work for me – I had to enter the names manually.)
o Insert the Yubikey you have chosen for this user, and click into the OTP field displayed, and touch your Yubikey button. (If you programmed into Config 2, you will need to hold the button for 4 seconds).
o The code will be validated, and the ROPII will from then on allow that user, and that user only, to authenticate with that specific Yubikey.
o Do the same with the other users.
o The system has an ‘auto provision’ mode which does not require you to do these steps, but I only had 10 keys, and I wanted to check everything. (Also, I tried the auto provision and it did not work the first time, and I couldn’t be bothered tracking down why not)
• Congratulations, your server is now set up, and ready to authenticate your users. All you need do now is set up the client end, and you are done.
CLIENT SETUPThe client setup involves installing, on your user PC, a module called pGina and a Radius capable DLL file, and configuring both of them to work together, and with your ROPII server.
This can be done on any (or all) of your PCs in your LAN. PCs where you have performed this step will require the OTP from the Yubikey as part of the authentication process. PCs which have not had the client installed will continue to login with just user and password without needing the Yubikey OTP.
I wanted to use the Yubikeys for remote authentication, so I installed the client software onto the PC inside our LAN that we use as a terminal server for our remote users. This way, the remote users connect to our LAN as normal, using the same method they always have: - either VPN or the VPN_via_Internet_Explorer system known as Remote Web Workplace (which comes built in to Small Business Server 2003 and up*). Then, once connected to the LAN (which in our network, gives them access to the terminal server PC ONLY), the user opens an RDP session to the terminal server PC and, because the Client side of this solution has been installed on that PC, the remote user must then use their Yubikey to supply a valid OTP, or they cannot log in to our domain. *Using Remote Web Workplace requires that you enable RADIUS passthrough from your AD server to your ROPII server in your TS Gateway Authorisation policy on your NPS (Network Policy Server). As soon as I figure out how to get this working, I will post the instructions
So, to set up the PC:
• First, download the Guide “YubiKey authentication for Windows login using pGina and RADIUS” from here:
http://www.yubico.com/documentation• The guide tells you where to download pGina and the Radiusplugin DLL you need. Note that you need the older version of pGina (ver 1.x) for client PCs running Windows XP and below, and you need the new version (ver 2.x) for Windows Vista and above.
• Before you install pGina, beware! pGina takes over your PC’s default authentication module. If it all goes wrong, you may be unable to log in. At all. I used a virtual PC for testing, and took a snapshot before I started, so that I had a second chance if it went wrong. I needed my second chance! If you are using a physical PC, make it one that you can easily re-image if needs be.
• Follow the installation instructions from the user guide. Start at page 9. I was doing an installation to a Windows XP system, the instructions for which kick off at page 17.
• Make sure you install pGina AND the RADIUSplugin.
• I strongly recommend you look at the pGina documentation that installs itself with pGina, but AFTER you have followed the key instructions in the user guide and this post. There are some cool options for customising the logon screen with your logo and stuff . Also the ‘passthrough’ mode is pretty handy to know about, and it is tucked away under the scary ‘Advanced’ tab.
• pGina Settings :
o Plugin tab:
The guide shows the ‘Show authentication method selection box (Experimental)” as selected. This is essential during testing phase, but you will want to turn this off once you have tested everything, as it gives the user the option of bypassing the OTP authentication system . It defeats the entire purpose of introducing two-factor authentication if the user can choose not to use it! During testing, though, if your first authentication attempt does not work as expected, you can change to ‘domain authentication’ and then log in without the OTP. You need to log in to change the settings, so you need a fallback in case it doesn’t work the first time.
Configure the Radiusplugin DLL as per the guide. You need to give it the ip address of your ROPII server so it knows where to send the authentication requests. You need to make up a cool password, and enter this into the ‘secret’ field corresponding with your ROPII server. Then switch to your ROPII server web interface, go to the Configuration tab for your domain, and fill in the “Add Client” fields. You need to tell it the ip address of the PC you are setting up, and enter (2x) the password you just made up and entered as the ‘secret’ in the RADIUSplugin config page. Click “Add” and you should get confirmation that the PC you are setting up is now a Radius client known by your ROPII server.
Now switch back to your PC, and apply the settings you have configured for the RADIUSplugin.dll.
Don’t log off yet, you need to set some more pGina settings.
o Logon Window tab:
Go on, put your own logo in. It looks great!
I recommend filling in the “Message of the Day” text with detailed instructions to the user about how to log in. This will be what they are looking at at the time they are logging in, and you know they won’t remember everything you told them...
I disabled the 3rd button, as I don’t want my users shutting down or rebooting my terminal server.
o Locked Window tab:
Go on, put your logo in here too!
o “Advanced” tab
Note the ‘passthru mode’ option. After you set this machine up, you can leave it in passthru mode until you have given out the Yubikeys to all the users who need them. They won’t even know you have touched the machine. When you are ready, uncheck this option, and the Two-factor authentication logon screen will magically appear at next logon.
o “Account Interaction” tab.
If, after a successful OTP authentication, instead of proceeding to log you on, you experience an error something like ‘unable to create profile due to unknown error’, try this option.
This is likely related to the fact the PC I was setting up is a terminal server, and may not be required in every case.
I found that when I tried the pGina setup initially, the login failed because pGina was attempting to create a user profile on the local machine, but the local machine was rejecting the attempt, on the basis that the user had not yet been authenticated, and hence was not allowed to write a profile to the machine!
The workaround was to create a ‘pGinalogon’ account with user level rights on the local machine (user level rights were all that were required) and then, in the ‘Account Interaction’ tab, select: “Enable single user logon”, and put in the username (“pGinalogon’) and password you created for it, and the local pc name as the ‘domain’ (not the actual domain for your LAN, you are just giving local pc rights here).
• Once you have done this, you should be set up. All you need now is to test it. I still wouldn’t be logging off yet, as I want to be really sure I will be able to log back in again first.
• pGina comes with a wonderfully handy test program that lets you verify your logons are working, without actually having to log off and on.
o The link to it is created in the same folder as the ‘configure’ link, and is called “Plugin Tester”. It opens a separate basic test program.
o You have to tell it that you want it to use the “RADIUSplugin.DLL” you have downloaded, by clicking the ‘browse’ button and selecting the dll. (It will be in C:\Program Files\pGina\plugins\RADIUS )
o You can then enter the username and password, and it will tell you if you ‘passed’ or ‘failed’ authentication.
o You need to enter the username and password in a special way, both to pass the test, and to actually log on using this function.
The username is now CASE SENSITIVE. This never happens in a Windows environment, but Linux is case sensitive, therefore ROPII is case sensitive. If ROPII has the user Login Name as ‘fredsmith’ then ‘FredSmith’ will FAIL authentication, even if he has the right password and OTP. (May I recommend to Yubico to change this in future versions ?!)
The username needs to have the LDAP DC names appended to it. Using our example DC of DC=mybusiness,DC=local, if the username were “fredsmith’, the user would need to enter: ‘fredsmith@mybusiness.local’
The user needs to enter their usual password into the password field. Then, leaving focus on that field, and the cursor at the end of their password, you touch the Yubikey button to append the Yubikey OTP. (note that ‘fredsmith’ needs to be one of the users you have already set up in the ROPII server, and the Yubikey you use must be the exact one you have allocated to fredsmith on the ROPII server. The steps to do this are set out in the SERVER SETUP section above)
The test program will then send this info to your ROPII server, which will respond and tell the pGina whether the user passed, and should be allowed to log in, or failed.
If you passed, you are working! Try it with a real log in.
One thing I found, the test program did not like the option I had specified in the Yubikey “append Enter to the OTP”. The ‘enter’ command sent at the end of the OTP string dismissed the test program without telling me the result. The workaround was to put the cursor into a Notepad application, touch the yubikey to trap the password generated, then cut and paste it into the appropriate position in the test program. (The ‘enter’ option in the Yubikey is no problem for the pGina login itself, only the test program.)
o Once you are happy with your authentication, remember to go back and turn off the ‘passthru’ option (if you set it), and the ‘Show authentication method selection box (Experimental)”.
Having done all of this, you should have one or more PCs on your local LAN that require two factor authentication to log in. Use one or more of these as the PC to which your remote users log on (via RDP) after connecting to your network, and you have two factor authentication for remote users with no changes to the PC being used by the remote user.
Login
FAQ
Search
So, in order to make the vpn connection, I would need to ensure that my vpn connection is unencrypted - hardly ideal, and somewhat ironic for a security solution...