Modifying YubiRadius to authenticate only the OTP for use with Citrix Access Gateway

For those that aren't aware the Yubico Yubikeys are a fabulous product, a one time password token built with flexibility in mind. Don't want to use Yubico's cloud based authentication servers? No problems run your own, don't trust the Yubico AES keys that comes with the Yubikeys? No problems, add your own keys.

One initial drawback of the Yubikey was their limited use in the enterprise space, if you wanted to use them within the enterprise you needed to write your own authentication mechanisms to tie in with the Yubico API. Enter YubiRadius, a yubikey radius solution that ties together freeradius, apache and some custom php scripting to deliver combined LDAP/Yubikey authentication.

Not all enterprise applications are able to use two separate radius servers (LDAP radius then YubiRadius). With this in mind Yubico has addressed that by requiring the user to enter their password immediately followed by a OTP in the password field. This is a great solution and really opens up a number of new potential ways of how Yubikeys can be applied.

One of the biggest limitations of entering the password + OTP in one field is single sign on. Using a product like Citrix Access Gateway (CAG) that takes the initial username and password and passes them through to the Xendesktop/Xenapp instance sitting behind the CAG, this will never work. What CAG does support though is a dual password field, the first would be the normal LDAP password field that is used for the pass-through and the second field can be a radius server.

As you could imagine users wouldn't be impressed knowing they have to type their password into the LDAP password field, then again into the YubiRadius password field and ALSO insert their Yubikey for OTP. The solution for this is using YubiRadius is OTP only mode, this way it purely focuses on validating the OTP against the LDAP username.

Unfortunately out of the box YubiRadius doesn't support OTP only authentication, but with a few modifications to the /var/www/wsapi/ropverify.php file we are able to gain the desired results without breaking any password + OTP logins that may occur.

The below modifications change the ropverify.php file to first check the password length. If the password length is 44 characters then there is no password present (YubiID+OTP is 44 characters), resultantly LDAP password verification is skipped. If it is not 44 characters in length the password field is treated as per default, both LDAP password and OTP are verified independently.

If you have manually changed your Yubikey keys and your YubiID+OTP result in a string longer than 44 characters in length, you will need to make a modification to my code changes to reflect that.

While this works great in my environment, I would suggested if you want the highest level of security then you should use multiple instances of YubiRadius, one of OTP only authentication and another for LDAP password + OTP authentication.



Step by Step

NOTE: This was done on version 3.5.1 of YubiRadius, use it at your own risk. 

1. Jump onto your YubiRadius box either via the console or SSH and su to root.

2. Navigate into the /var/www/wsapi folder
cd /var/www/wsapi

This is where the ropverify.php file is. FreeRadius sends a request to ropverify.php and ropverify verifies that both the LDAP password and the OTP line up with the LDAP username.

3. Download my patch file from pastebin, a wget should do the job. Name the downloaded file ropverify.patch
http://pastebin.com/raw.php?i=K8U95nx5

4. Take a backup of your ropverify.php in case something goes wrong.
cp ropverify.php ropverify.php.bak

5. Issue the following command to patch the existing ropverify.php

patch ropverify.php < ropverify.patch

The file should now be patched and ready to go, you still need to make one change to enable OTP only logins.

6. Edit the ropverify.php file

nano ropverify.php

7. Find the line that reads:

$otpOnlyAuthAllow = 0; //change to enable OTP only

Change the 0 to 1, and if you want to disable it, change it back to 0.


It really is as easy as that. Now you can have users login with only the OTP or with both the password and OTP in the password field.

Please keep in mind you should disable auto-provisioning if you are using this script. If auto-provisioning is enabled, anyone with a Yubikey can potentially associate themselves with an existing LDAP account and bypass your two-factor authentication.

Exchange 2010 OWA users report a blank screen after first login

I recently provisioned a number of Exchange 2010 e-mail accounts as part of a mail roll-out project I was undertaking. The owners of these accounts prodominatly access their accounts via outlook web acces (OWA) using forms based authentication, both via a local instance and another instance sitting behind Forefront UAG.

Provisioning the accounts was the easy part.

The Problem

As soon as I started handing these accounts out, users were reporting the inability to get past the select language screen. Users were able to log in without issue, but after selecting an appropriate language and time-zone they simply recieved a blank screen. Anyone who was persistent enough to try 3 times in a row eventually did get in, and after they were in once, they didn't have any more problems.

After replicating the issue and confirming it was in fact happening, I checked eventvwr, exchange logs and IIS logs but I was unable to pinpoint what was causing the problem. In fact the logs had nothing unusual at all in them.

I was able to determine the blank screen was when the web browser was attempting to access the following URL: https://OWAURL/owa/lang.owa

The Fix

As the problem seemed to disappear after the user entered and accepted the time-zone and language data 3 times, I thought I would try forcing the local ID onto the OWA instances in question.

Voila, after executing the following command into an Exchange powershell console, users no reported any issues.

Set-OWAVirtualDirectory "owa (Default Web Site)" -DefaultClientLanguage <Locale ID>

You can use this table provided by Microsoft to search for your Locale ID.

If you are using a custom OWA instance with a different name, you can use the following command to get a list of all the OWA instances on your server.

Get-OwaVirtualDirectory

Hopefully you are smart enough to do this BEFORE you start adding accounts and not when users start having problems.