Configuring Forefront UAG trunks to support Yubico YubiRadius OTP authentication

In the process of preparing some of my external services for Yubikey integration I have been faced with a few problems, integration with Forefront UAG is no exception.

Adding the YubiRadius radius server to UAG as an authentication server is rediculously easy. Open the desired trunk properties, go to the authentication tab, add a new radius authentication server and put in your server IP and secret key.

After spending all of 2 minutes configuring YubiRadius as an authentication provider for one of my existing trunks I attempted to login and was repeatedly met with a generic UAG "Access Denied" screen.

I jumped onto the YubiRadius box via SSH and restarted freeradius in foreground vebrose debug mode by starting it with freeradius -f -X. Freeradius gave me a vital clue, UAG was only passing the first 20 characters of the OTP to the YubiRadius server, so of course YubiRadius was replying to UAG with access denied.



Fixing the Issue

The problem occurs because by default UAG only allows 20 characters in the password field, any more than 20 are automatically truncated back to 20 before being passed to the authentication server. In most instances this would be fine, but for OTP's it simply doesn't work. Luckily for us, the fix is a piece of cake.

1. Log into your UAG box and open the following folder "%programfiles%\Microsoft Forefront Unified Access Gateway\von\InternalSite\samples"

2. Copy the customDefault.inc from the samples folder to "%programfiles%\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate"

3. Edit the customDefault.inc and change the PasswordLimit field to 50 (or more if you are using a custom OTP length), as per below. You may even need to consider a length closer to 70 characters if you are using a shared field for Active Directory password and OTP.

4. Open a command prompt and issue an iisreset

Done like a dinner, your UAG server should now pass the full OTP token to Freeradius, to which it can properly validate if the token is authentic or not.

How to run Yubico YubiRadius on Microsoft Hyper-V

For anyone that might have read my blog posts in the past you would know I am an advocate of Yubico Yubikeys and in particular their implementation with YubiRadius.

YubiRadius allows the system administrator to host an in-house Radius server (I was about to write Yadius) that is the missing link between Yubikeys and anything that can interface with Radius.

Unfortunately YubiRadius only comes in OVF and VMware formats, which leaves anyone with Hyper-V infrastructure in a hole, but luckily its quite easy to get it up and running on Hyper-V



The Conversion Process

1. Download YubiRadius VMWARE edition from here http://yubico.com/yubiradius-vm


2. Grab the VMDK2VHD converter, it easily converts VMDK files directly to VHD for use in Hyper-V. You can download it from here http://vmtoolkit.com/files/folders/converters/entry8.aspx


4. Open VMDK2VHD, it will prompt you for a VMDK file, point it towards the YubiRadius VMDK file you downloaded in step 1. Select an output location for your VHD file and start the process.

3. Once the VHD has been created jump onto your Hyper-V box and create a new virtual machine, give it the following attributes.

Memory: 1024MB (or more if you want)
Legacy Network Adapater
and assign your newly created VHD file to the IDE controller.

The rest of the settings are up to your personal preference.

4. Take a snapshot before you start, just in case you hose something in the setup process. Then boot your new Hyper-V YubiRadius server.


5. Login with the default credentials.
Username: root
password: yubico

Once logged in the GUI may not load correctly, it didn't for me. A simple ctrl+alt+f2 will re-direct you to a working terminal. From here you can use update-rc.d -f remove to remove services you don't want to run at boot, such as the GUI X11.


6. We need to setup the network adapter so we can login via SSH for future configuration. Enter the following commands at the command prompt.

cd /etc/network
nano interfaces

Below are some example settings you can change and then paste directly into the interfaces file.

# The primary network interface
allow-hotplug eth0
iface eth2 inet static
        address 192.168.1.100
        netmask 255.255.254.0
        network 192.168.1.0
        broadcast 192.168.2.255
        gateway 192.168.1.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.1.1
        dns-search domain.internal

Make sure you hash out the #auto eth0 line, or you may have problems booting.

Press ctrl+x to exit, and type Y to save the changes.


7.  Next we need to add at least one DNS server to /etc/resolv.conf to enable DNS resolution. You can change the below IP address to reflect your DNS server.

echo 192.168.1.1 >> /etc/resolv.conf

8. Finally you can issue a reboot with the below command for the settings to activate.

shutdown -r now

9. After the system has rebooted, you should be able to SSH in and access the Webmin interface via http://IP:10000/

The default username is yubikey and the password is yubico.



It might be a good idea to setup an IPTables firewall and disable as many unrequired services as possible, YubiRadius is fairly loose by default.

If you hose the system (it doesn't reboot after you change the network settings) you can go back to the snapshot you took before you started. Ensure your network configuration is correct and you hashed out the #auto eth0 line after changing the interfaces file.

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.

iPhone native twitter app is not displaying mentions under the @connect tab

Recently my twitter stopped updating mentions under the @connect tab in the default iPhone twitter application. Initially I thought it was just me but after a quick google search I found a number of users were experiencing the same problem.

After first trying to restart and then playing with a number of settings I was unable to resolve the problem, but the following process worked.


The Fix

1. Open the Settings menu.

2. Select Twitter.

    

3. Click on the account that is causing you a problem, in my case it is "@teamau"

4. Click "Delete Account". This doesn't delete your twitter account, but just clears the account from your iPhone.

5. Click "Add Account" and re-add the account you just deleted.

Voila, your @mentions should be working again!

Sharepoint error "The security token username and password could not be validated" during claims based authentication configuration

There are many great tutorials on configuring Sharepoint 2010 (SP) to use claims based authentication such as this one by SharepointChick. Claims based authentication is a handy way to pair SP with a lightweight LDAP directory.

The configuration is reasonably complex and determining where an error lies is a balancing act between windows event viewer, LDAP logs and ULS logs.

One such error I received during my SP and OpenLDAP configuration was an event viewer application log.

Source: SharePoint Foundation
Event ID: 8306
Task: Claims Authentication
Error: An exception occured when trying to issue security token: The security token username and password could not be validated..

This error is accompanied with the inability to login to your SP site. A quick google search turned up a number of users in the same boat and plenty of suggestions but no definitive answers.

Clumsy Configuration

When you are working from configuration samples and writing large portions of text based configuration there is always the possibility of data entry errors.

Any of the tutorials you follow, such as this one, will ask you to create a new web application, select claims based authentication and then do some manual configuration in some of the web.config files on your SP site.

This is where the doubt creeps in, during the configuration of a membership provider, depending on the tutorial you are reading, you may be asked to configure a "ASP.net membership provider" with  "useDNAttribute" or "userDNAttribute" or both.

As soon as I removed "userDNAttribute" and set "useDNAttribute" to false, everything worked for me and the security token validation error message disappeared. I am not sure if this is because I am using OpenLDAP or if that makes any difference at all.

The below configuration is an example of my working membership provider syntax.

<membership>
<providers>
      <add name="LdapMember"
         type="Microsoft.Office.Server.Security.LdapMembershipProvider,
 Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral,
 PublicKeyToken=71e9bce111e9429c"
         server="192.168.1.1
         port="389"
         useSSL="false"
         useDNAttribute="false"
         userNameAttribute="cn"
         userContainer="ou=users,dc=contoso,dc=local"
         userObjectClass="inetOrgPerson"
         userFilter="(ObjectClass=inetOrgPerson)"
         scope="Subtree"
         connectionUsername="Cn=sharepointuser,dc=contoso,dc=local"
         connectionPassword="password"
         otherRequiredUserAttributes="title,sn,cn,mail,description"/>
   </providers>
</membership>

Looking back retrospectively it seems like an obvious and easy to fix problem, but when there are so many variables at play it isn't always so easy.

Sophos Enterprise Console 5 displays clients as "Awaiting policy transfer" after upgrade

I am yet to have a smooth Sophos Enterprise Console (EC) upgrade, there is always some certificate, configuration or downright weird issue. This time after upgrading from 4.7 to 5.0 everything seemed perfect, I should of known that was too good to be true.

After a policy change didn't find its want to my endpoint's I did some digging in EC and found nearly all of my endpoints were hanging at "Awaiting policy transfer". The only clients that were the "Same as policy" had been rebuilt since the EC upgrade took place.

Immediately I though of the dreaded Sophos certificate problem but further investigation ruled out this theory, fortunately the resolution was much easier.

Please update my policy changes!

1. Fire up EC 5

2. Right click any computer that is turned on but still "awaiting policy transfer", then select "View Computer Details"

3. Here you find the the status of all the policies on the selected client. For example "Anti-Virus and HIPS Policy", "Updating Policy" and "Application control policy".

Take note of all the policies that are "awaiting policy transfer", these are the ones we will need to fix.

4. The fix is ridiculously easy, edit one of the policies that are "awaiting policy transfer" and change one option. After changing the option, change it back to your original setting then press OK. Repeat for all policies hanging at "Awaiting policy transfer".

Huh? Hold on, I didn't change anything right? All I did was check an option then un-check it. Correct! But what I did do was trigger a policy update of old EC 4.7 policies. I am not sure if this changes some underlying configuration or perhaps updates an out of date check sum, regardless of what is happening behind the scenes it resolves my problem.

In the below image I opened my "Tamper Protection Policy" which was "awaiting policy transfer". I then checked "enabled tamper protection", then immediately unchecked it and clicked OK. Shortly after my clients begin receiving the updated policy.

 

Savour this fix, it's the easiest Sophos resolution you will ever get.