SaaS/PaaS conversations are coming up more and more in my customer meetings. I think it is important to understand the difference between authentication and authorization and what fits a cloud model and what does not. This post does a great job of outlining some of the strengths F5 Access Policy Manager provides in regards to authentication as well as APM’s ability to help you consolidate solutions/infrastructure.
Employee collaboration and access to communication tools are essential for workplace productivity. Organizations are increasing their use of Microsoft Office 365, a subscription-based service that provides hosted versions of familiar Microsoft applications. Most businesses choose Exchange Online as the first app in Office 365 they adopt.
The challenge with any SaaS application such as Office 365 is that user authentication is usually handled by the application itself, so user credentials are typically stored and managed in the cloud by the provider. The challenge for IT is to properly authenticate the employee (whether located inside or outside the corporate network) to a highly available identity provider (such as Active Directory).
Authentication without complexity
Even though Office 365 runs in a Microsoft-hosted cloud environment, user authentication and authorization are often accomplished by federating on premises Active Directory with Office 365. Organizations subscribing to Office 365 may deploy Active Directory Federation Services (ADFS)…
If you’re using Citrix StoreFront 2.6 and following the Citrix-VDI-iApp 2.0.0 deployment guide you may run into a snag while creating the Citrix Client Bundle for HTML 5 support (on page 45). In StoreFront 2.6 the Citrix HTML5 Receiver is no longer a standalone MSI file but is now bundled into the StoreFront 2.6 executable. This post will walk you through the process of extracting the HTML5 Receiver MSI to get you past this snag.
Open 7-Zip File Manager (or your prefered product)
Select the CitrixStoreFront-x64.exe file and then Open Inside (Ctrl+PgDn)
Select the Html5Client.zip file and then Open Inside (Ctrl+PgDn)
4. Select the template folder and the Open Inside (Ctrl+PgDn)
Select the HTML5Installer.msi and Click the Extract button
Now that we have the MSI file you can proceed with the steps in the iApp deployment guide (page 45 if you forgot where you left off).
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:
Change the text for Logon Page Input Field #1 to:
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.
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:
Enter the following expression: (click change and then select the Advanced tab)
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.
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
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.
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.
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.