Prepopulate APM Username From O365 Login

emojiF5’s Access Policy Manager (APM) offers many compelling security and optimization features for Microsoft’s Active Directory Federation Services (ADFS) – more info in the APM/ADFS Deployment Guide.  Odds are if you’re deploying ADFS you’re also using or looking at Office 365.  Normally, when you login to O365 you will be redirect to a Home Realm Discovery page,  This page does 2 things:

  1. determines if you’re a federated users (i.e. you use another authentication source like F5, MS ADFS, Okta, …. <insert long list of IDMs on the market today>).
  2. if you’re not a federated user, authenticate you against Azure AD.
Office 365 Empty Login Page

So when you type in your email address Microsoft parses the domain name and automatically redirects you to your local APM/ADFS environment for authentication – pretty nice! However, when you land at the APM login page you notice the username field is empty and you have to enter your username or email address (depending on how APM is configured for authentication) again.

You can fix this by customizing the APM Visual Policy Editor to look for O365 to ADFS logins and prepopulate the username.

Username Prepopulated from O365

So what does the APM configuration look like?

Final VPE

Step 1: Create an object to detect O365 to ADFS Login 

  1. Click the (+) button on the Start fallback branch
  2. In the search box type empty and select the Empty resource then click “Add Item”
  3.  Name the resource O365 Login
  4. Click on the “Branch Rules” tab and click “Add Branch Rule”
  5. Name the branch “Yes” and add the following expression via the advance tab
    • expr {[mcget {session.server.landinguri}] contains “username=”}
  6. Click Save


Detect O365 Login


Step 2: Extract the Username from the O365 Redirect Request

When the user enters their email address into the O365 login this data is included in the GET request back to the APM/ADFS environment.

O365 Login with Federation Redirect
O365 Redirecting to APM/ADFS

To capture this data we’ll need to create perform the following steps:

  1. Click the (+) button on the Yes branch off of O365 Login
  2. In the search box type variable and select the Variable Assign resource then click “Add Item”
  3. Name the resource “set username from O365” and add the following variables

session.logon.last.username = expr {[string range [mcget {session.server.landinguri}] [mcget {session.custom.pos_username}] [mcget {session.custom.pos_at_sign}]] }

session.custom.pos_at_sign = expr {[string first “%40” [mcget {session.server.landinguri}]] – 1}

session.custom.pos_username = expr {[string first “username=” [mcget {session.server.landinguri}]] + 9}

Click “Finished” and then click “Save”

Set Custom Variables

Step 3: Customize the APM Logon Page

Now that we have the username we need to prepopulate it on the APM Logon page and set the form variable to read only.

  1. Click the (+) button on the “set username from O365” fallback branch
  2. Select “Logon Page’ then click “Add Item”
  3. Name the resource “O365 Logon Page”
  4. Change the “Read Only” setting for field 1 to “Yes”
  5. Click  “Save”
APM Logon Page

The remainder of the VPE configurations are basic and are not covered in this article to keep it from being a novel.

That’s it!  Now you’re user’s only have to enter their information once which will definitely make them happier.

APM Cookbook: Multiple Domain Authentication – Part 2

In this series we examine ways to make APM authenticate against multiple Active Directory Domains.  Part 1 discussed the use of a drop down menu on the APM login page.  In Part 2 we use the user’s UPN to determine the correct domain for authentication.

Note: If you are following along through the series I recommend that you create a new APM Access Profile for Part 2 versus modifying the Access Policy from Part 1.

Home Realm Discovery / Where Are You From

Depending upon your experience with multi-domain and/or federated authentication the terms “Home Realm Discovery” and/or “Where are you From” may seem odd.  The basic principal of this page during an authentication process is to determine the user’s authentication domain/source by asking a question or providing a list of accepted domains/sources.  In our example we will ask for the user’s UPN and based upon their response APM will choose the corresponding Active Directory domain for authentication.

For those that like to see the big picture first the image below provides an overview of the completed Visual Policy Editor for our Access Profile.


So lets get started…

Home Realm Discovery Logon Page

In an empty VPE add a Logon Page action between the Start and Deny ending (click the (+) button if you’ve never edited the VPE before).  Next you will need to make the following modification and then click Save.

  • Change the type for Logon Page Input Field #2 to:
    • None
  • Change the text for Logon Page Input Field #1 to:
    • UPN
Home Realm Discovery Logon Page Action
Home Realm Discovery Logon Page Action

Convert UPN to Username

Since APM’s AD auth action by default authenticates users by username and not the UPN we’ll need to extract the username from the UPN.  For this step you’ll need to add a Variable Assign action after the Home Realm Discovery Logon Page.  Make the following modifications and then click Save.

  • In the Custom Variable text box enter:
    • session.logon.last.username
  • In the Custom Expression text box enter:
    • expr { “[lindex [split [mcget {session.logon.last.username}] “@”] 0]” }
Obtain username from UPN
Obtain username from UPN

Determine Authentication Domain

Next we’ll need to examine the UPN and determine which domain to user for authentication.  For this step you’ll need to add an Empty action and create two Branch Rules (2nd tab at the top of the action window).  Once you’ve configured your Branch Rules click Save.

Note: It is important that if you are copying/pasting the expressions that you remove any newlines that may result from browser formatting.

  • Change the 1st Branch Rule’s Name to:
    • Contractor
  • Enter the following expression: (click change and then select the Advanced tab)
    • expr { [string tolower [mcget {session.logon.last.logonname}]] contains “” }
  • Change the 2nd Branch Rule’s Name to:
    • Employee
  • Enter the following expression:
    • expr { [string tolower [mcget {session.logon.last.logonname}]] contains “” }

Notice we’re examining the logonname and not the username.  This is because the username was previously changed.  The logonname is set by the Home Realm Discovery Logon Page and offers us a pristine copy of the UPN.

Determine AD Domain for Authentication
Determine AD Domain for Authentication

Domain Specific Logon Pages

Next we’ll need to create domain specific logon pages to request credentials.  For each branch, contractor and employee, you’l need to add a Logon Page action and customize each logon page with the below settings and then click Save.

  • Set the Read Only option to Yes for Logon Page Input Field #1 
Contractor Logon Page Action
Contractor Logon Page Action
Employee Logon Page Action
Employee Logon Page Action

In this example I am only asking for the user’s password but this demo could easily be modified to require multi-factor authentication and/or send the user to RSA for risk based authentication.

Domain Authentication

From here, you can add an AD Auth action to each branch, contractor and employee, and configure the Server to the corresponding AAA object for the selected domain.

End Results

The final results will prompt the user for their UPN, then their password and authenticate the user against the desired domain.  In the next post we’ll look at ways to obtain the correct domain by querying the Active Directory Global Catalog or specific domain.

Home Realm Discovery
Home Realm Discovery
AD Authentication
AD Authentication