Category Archives: ADFS

ADFS SSO Primers

by
AD FSCloud, Office 365
SSO means different things to different people – make sure you’re talking about the same thing (i.e. Single Sign-On, Simple Sign-On or Same Sign-On)
In order to transparently obtain a claim from ADFS the following must be present:
  1. Your browser or client application needs to support WIA and claims
    IE/Edge support WIA out of the box, Firefox can reportedly be configured to support it (Chrome and others possibly as well using the same steps)
  2. Your browser must be talking to the intranet ADFS servers (as talking to the ADFS proxies takes you through forms-based authentication)
    This is frequently done through either a split-brain DNS setup or a network device that routes internal claim requests directly to the internal ADFS servers and external claim requests to the ADFS proxies
  3. Your browser must trust that the ADFS farm is an intranet web site that (the site should be in the Local Intranet sites in Internet Settings)
    Adding a GPO setting to include the ADFS farm name will work, targeting the GPO at the Computer gives the User the flexibility to add any required additional entries as the user settings inherit any sites added at the computer settings level.
  4. You must be logged on to a domain-joined machine as the user you expect SSO to be provided for
    Note that a cached logon doesn’t really count as a proper logon (you’re simply being allowed access to local resources on the workstation based on a previously successful logon)
  5. The Relying Party application should redirect you to the ADFS farm when it detects you are attempting to log on using an account beloging to a domain suffix that their IDP is responsible for
    This should preferably done immediately upon entering the account name when switching focus to the password field, entering the password at the RP side shouldn’t be required at all (f.x. an onFocus event targeting the password field, similar to what https://portal.office.com does).

 

ADFS and SSO
http://blogs.technet.com/b/abizerh/archive/2013/04/11/more-information-about-sso-experience-when-authenticating-via-adfs.aspx

Support for Windows Integrated Authentication in Firefox
http://justgeeks.blogspot.co.nz/2011/01/firefox-supports-integrated-windows.html

Configuring Chrome and Firefox for Windows Integrated Authentication
http://www.sitehelpdesk.com/sitewebdesk

onFocus event
http://www.w3schools.com/jsref/event_onfocus.asp

Split-Brain DNS
https://msdn.microsoft.com/en-us/library/ms954396.aspx

A faulty split-brain DNS configuration can prevent a seamless SSO sign-in experience
https://support.microsoft.com/en-us/kb/2715326

Office 365 Single Sign-On with AD FS 2.0 whitepaper
http://www.microsoft.com/en-us/download/details.aspx?id=28971

A federated user is prompted unexpectedly to enter their credentials when they access an Office 365 resource
http://support.microsoft.com/kb/2535227

A federated user is repeatedly prompted for credentials when he or she connects to the AD FS 2.0 service endpoint during Office 365 sign-in
http://support.microsoft.com/kb/2461628

Working simultaneously with multiple user accounts in O365

by

Mongo

When you have Windows Integrated Authentication (WIA) turned on for the ADFS server and it is included in the Local Intranet site in IE settings you will always get automatically logged on as the currently logged on user regardless of who you attempt to log on as.

 

So let’s say you have an admin account in O365 called Super-Man@Contoso.com that you want to use for administering O365 while your normal login name is Man@Contoso.com.
You open up an in-private browser window for O365 and enter your login name Super-Man@Contoso.com into the browser window – hoping to get redirected to your ADFS server where you would enter your alternative credentials.
The results: you get redirected to your ADFS server and WIA logs you in as the currently logged on user – Man@Contoso.com.
This is just the flipside of SSO – turning this off to cater for the subset of users that want to use multiple accounts in O365 (typically your admin team) will force all your users to enter credentials specifically rather than use SSO from the current logon credentials.
I.e. you can’t have your cake and eat it*
A quick workaround is to create a shortcut on your desktop that launches a browser using RunAs (f.x. if you have adminaccounts prefixed with Super-):
C:\Windows\System32\runas.exe /user:%userdomain%\Super-%username% “%ProgramFiles%\Internet Explorer\iexplore.exe”

*unless you buy two cakes

Tracing Issued Claims in ADFS

by
Quick & Dirty scripting tools – the following Powershell script will dump the last X minutes of issued claims on an ADFS server (Assuming Auditing of Issued Claims has been turned on in the AD FS Management MMC).
$timeView=-5
if($Args.count -gt 0) {$timeView=$args[0]}
$StartTime = (Get-Date).AddMinutes($timeView)
$output=Get-WinEvent -FilterHashtable @{
LogName = “Security”;
StartTime = $StartTime;
ID = 501}
$output |fl
“Total issued claims:$($output.Count)  $($timeView) minute view”