Yubikey Authentication with Outlook Web Access

I’ve recently been evaulating Two-factor Authentication (2F) implementations for one of our clients, including the excellent Yuibikey product from Yubico.

The initial requirement for our client project is 2F protection of all remote-access to their systems, which presently only amounts to VPN connections and webmail access via Outlook Web Access (OWA) provided by Exchange 2007.

We’ve now finished implementing this, and the diagram below shows how we protected the OWA service (I might cover VPN in a later post). Naturally there are a wide variety of ways to provide 2F authentication for OWA, but I think this presents the best end-user experience:

Authentication Process Overview

Authentication Process Overview

First, a quick overview of the highlights:

  • We implemented a domain-joined ISA Server 2006 Standard.
  • We customised the default 2F ISA Server OWA login wrapper. By default it requests Username, OTP (one-time password) and finally the “internal” password (i.e. the domain password). We thought this was a little counter-intuitive for our users, since the OTP is the new credential being requested (in addition to the usal username/password combination) we thought it should be the last field on the form. Also, our Yubikeys are configured to emulate an ‘enter’ keypress after populating the field, which means that the Yubikey OTP needs to be the last field filled out by the user since it causes the form to be submitted. Finally, the default ISA OWA login form contains an option to add a second username for internal use. We removed this since we don’t have different usernames for remote access.
  • We modified the Active Directory Schema to include a new field on the User object, contianing the user’s Yubikey Public Indentifier. In this way we are able to verify that the Yubikey used to generate the OTP matches the Yubikey assigned to the AD user. This appears to be a unique solution; all the other implementations that I’ve seen require a separate mapping table of user accounts to Yubikeys, usually on the RADIUS server. This is annoying, since it means that you’ve got another system to modify every time a new key is deployed.
  • All the FreeRADIUS modules that we used are entirely custom in-house code. Their function is described in detail below.

Examining our final implementation step by step:

  1. We present our custom ISA / OWA login form to the user over a secure HTTPS connection, where we collect the AD username, AD password and their Yubikey OTP.
  2. The ISA Server is configured to use RADIUS-backed OTP authentication for this service entry, which means that it sends the username and OTP to our FreeRADIUS server (note that the AD password isn’t sent, since we don’t need that).
  3. On the FreeRADIUS Server we have a custom validation module that communicates with the Domain Controller via LDAPS (secure LDAP) in order to confirm that the user exists in the Active Directory (AD). The module allows us to specify particular CNs and OUs in the LDAP tree to search within.
  4. Once the user has been located in the AD, the LDAP function retrieves the Yubikey Public ID of the Yubikey assigned to the user being authenticated. As mentioned earlier, we store this mapping in a custom AD field that we added to the schema. This Yubikey ID is compared with the ID of the key used to generate the OTP to ensure that the key is authorised for that user (for those unfamiliar with the Yubikey, the public ID can be trivially extracted from the OTP).
  5. Next, the FreeRADIUS module communicates with our own Yubikey Validation Server running on Glassfish (we could easily switch this to another server) using the standard Yubikey validation API. This ensures that the submitted OTP is valid.
  6. Assuming all of the above was successful the RADIUS server sends an ‘Accept’ response back to the ISA Server. To clarify, the following must be true:
    1. The user must exist in one of the configured AD OUs or CNs.
    2. The user must have a Yubikey ID assigned in their AD record.
    3. The submitted Yubikey ID must match the ID stored in the AD.
    4. The OTP must validate successfully against the validation service.
  7. Finally, if the RADIUS response was positive, the ISA server provides a delegated login to the OWA service. This means that the user doesn’t need to login a second time, so it’s essentially a form of SSO (single sign on). In order for this to work, the OWA service on your Exchange CAS server must be configured for NTLM (or basic) authentication as opposed to forms authentication.

Hopefully I have provided a coherent overview of our solution. I will try and follow this up with more details on the custom ISA forms, the LDAP schema modifications and FreeRADIUS integration in future posts.

As always, feedback is welcome!

This entry was posted in Security and tagged , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Tasis
    Posted November 19, 2009 at 2:01 pm | Permalink

    Very nice post, thanks very much!

    A quick question on the basis of what you have described: is there an easy way to extend the Active Directory authentication mechanism (AD username & AD password) to allow it to use the Yubikey one-time-passwords?

    I was thinking of the following:

    1. login to the AD server by passing your AD username and your Yubikey OTP

    2. the AD server validates the AD username and then performs a query regarding the validity of the password to the Radius server (by providing the Yubikey ID related to the AD username and the OTP password)

    3. the Yubikey server validates the OTP password against the Yubikey ID and reports to the Radius server

    4. the Radius server reports back to the AD server regarding the validity of the password

    Is such a variation of your method possible? I suppose this comes down to the question if an AD server can delegate the password authentication to an external service such as a Radius server (and I am not that knowledgeable in Windows AD security).

    Thanks for any insight you could provide.

  2. Jesper Nexø Jørgense
    Posted July 2, 2010 at 9:58 pm | Permalink


    Did you have further details on your implementation? It looks interesting :-)



    • Timothy Creswick
      Posted July 23, 2010 at 9:19 am | Permalink

      I can certainly provide further details.

      What were you specifically interested in?

  3. Jesper Nexø Jørgense
    Posted October 25, 2010 at 3:35 pm | Permalink

    Specifially I’d like to enquire about the custom module that validates users on the radius-server. Can you shed any light on the code?

    • Timothy Creswick
      Posted October 25, 2010 at 3:43 pm | Permalink

      Unfortunately I can’t provide the module code as this is a business asset, and something that we have continued to develop in the last year since I posted this article.

      The blog post covers the procedural process of the custom module, which is as much as I can freely give-away. The same applies to the YubiKey authentication server, which is now also a custom implementation, since the Yubico Java server is no longer supported and also contained several bugs and shortfalls.

      If you are interested in this commercially, I would be delighted to discuss this solution with you. You can find more information and contact details at http://www.vorboss.com, and also our Yubico integrators entry here http://wiki.yubico.com/wiki/index.php/Integrators:Vorboss_Ltd.

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

What is 15 + 2 ?
Please leave these two fields as-is:
IMPORTANT! To be able to proceed, you need to solve the following simple question (so we know that you are a human)