Introduction
With the new Office 365 sign-in experience you can capture the username entered at the O365 login page! This has been a frequent request from Office 365 users federated via SAML so users don’t have to enter their username twice when performing SP initiated logon and getting redirected from O365 for authentication.
Using the new O365 Sign-In Experience
Here’s the new sign-in experience I’m talking about:
If you try the new sign-in experience, it will post the username along with the SAML AuthN request. That’s what we need to prefill the username field for them. Once you try it, a cookie is set and you’ll continue to use it unless you click the link on the sign-in page to use the old sign-in experience.
Improving Your User’s Logon Experience
(Updated iRule should work with all browsers)
when HTTP_REQUEST {
# Check for for SAML POSTS
if { [HTTP::uri] starts_with "/saml/idp/profile/redirectorpost/sso" && [HTTP::method] eq "POST" } {
# Collect up to 1Mb of request content
if { [HTTP::header exists "Content-Length"] && [HTTP::header "Content-Length"] < 1048577 } {
set content_length [HTTP::header "Content-Length"]
} else {
set content_length 1048576
}
if { $content_length > 0 } {
HTTP::collect $content_length
}
}
}
when HTTP_REQUEST_DATA {
# Parse the username from the collected payload
set username [URI::decode [URI::query "?[HTTP::payload]" username]]
HTTP::release
}
when ACCESS_SESSION_STARTED {
if { [ info exists username ] } {
ACCESS::session data set session.logon.last.username $username
}
}
Now you’ll need to customize your access policy. You will need to replace your existing Logon Page object with a new macro. The is the end result we’re looking for:
First is the Username Check. You’ll need to add an empty object (click +, general purpose tab, empty). You want to create a branch rule, use advanced, and enter the following:
expr { [mcget {session.logon.last.username}] ne "" }
Next, the AD Query (authentication tab). The purpose of this object is to find the matching AD account for the email address that Office 365 sends. Normally it will match your user’s UserPrincipalName (UPN), so you can see we’ve customized the search filter to look for a matching UPN instead of the default which is a matching sAMAccountName.
If that’s not the case, you can change the search filter here, for instance yours might match the mail attribute if you’ve not modified your UPNs as is standard practice for O365. Also note that I’ve changed the branch rule, we don’t want the default of checking the primary group ID. We just want to know if the query was successful (did we find a match).
Here's what you'll enter into the search filter assuming you have set UPN to match O365 email.
userPrincipalName=%{session.logon.last.username}
If all your sAMAccountNames are just the first part of the email address, you can leave out the AD Query, Variable Assign, and Logon Page – Username Found But Invalid objects and just check the box for “Split Domain Name From Full Username” on the Logon Page – Username Found object.
Next, the variable assign (assignment tab). This object takes the sAMAccountName we got from the AD Query and puts that value into the username variable. Put session.logon.last.username on the left side, and on the right side select AAA attribute, AD, Use user’s attribute, and the attribute name is sAMAccountName.
Finally, the logon page (logon tab) for when O365 sends us the email and we find a matching username. Note that it’s just like your normal logon page, but you set the “Read Only” value to yes for the username field. This will cause the matching username to show up there.
Notice there are two other logon pages there, one for when no username is found and one for when there is no AD match to get a sAMAccountName for. Those are standard, nothing special. I’ll include pictures here anyway.
And now when you logon using the new O365 sign in experience, this is what you’ll see:
Give it a try, you'll make your users happy!
