ADFS and Windows Integrated Auth

  • 57 Views
  • Last Post 3 weeks ago
kool posted this 3 weeks ago

I keep hearing that ADFS supports Integrated Windows AuthN. That is, on a domain-joined computer you go to an ADFS-protected website and it will silently log you in (where the ADFS is in the same domain). In practice I've never seen this happen. E.g. on my domain-joined machine I go to one of our Office 365 web apps and get a login screen. I enter my email address which AAD uses to locate the correct tenant, then it uses the federation setting to call into our ADFS farm.

I think the rub is the fact that we have our Shibboleth SAML IdP configured as the second claims trust provider and have the O365 RP configured to go straight to it. Presumably it would have to use AD as the claims trust provider and authenticator to get IWA. Does this sound like a reasonable conjecture?

Thanks,

Eric Kool-Brown (kool@xxxxxxxxxxxxxxxx)
Software Engineer, UW IT IAM


Forum info: http://www.activedir.org
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx

Order By: Standard | Newest | Votes
bdesmond posted this 3 weeks ago

Yes, this works well in a normal deployment. I think your assertion is entirely accurate. AD FS is never even authenticating the user in your case - it's just a middle man.

Thanks,
Brian Desmond

w - 312.625.1438 | c - 312.731.3132.

show

dloder posted this 3 weeks ago

Which part are you complaining about?  The O365 "login" prompt starts as a home realm discovery (HRD) action, not a real login.  You could put in mickeymouse@xxxxxxxxxxxxxxxx and still get redirected appropriately.  When you're federated, that input only cares about the domain portion.
When you hit ADFS (or Shib as it's ultimately technology agnostic) do you get a username/password prompt that requires your on-prem credentials?
That's what ADFS IWA controls.  When you hit the ADFS website, it should (will) prompt for auth.  That prompt can be either forms based or browser based (Error 401 authentication required response).  IWA requires the browser based prompt, and when IE/Edge is configured correctly, they will automatically respond to the authN request by returning a Kerberos ticket for the ADFS SPN or an NTLM challenge response if Kerb wasn't properly enabled.
That one interaction between the browser and the ADFS website is the start and end of IWA.
From your example workflow, you don't mention an ADFS prompt (you only mention the O365 prompt), so I will assume that IWA is in fact working.  If you fiddler trace and see the browser automatically respond to the prompt you can validate my assumption.
To remove the HRD prompt requires changing some behavior some how, typically by embedding an HRD hint somewhere in the URL.  A common method is provided by the HRD acceleration URL that works with MyApps.  If your URL looks like https://myapps.microsoft.com/domainhint (e.g. https://myapps.microsoft.com/uw.edu) you will bypass HRD and get automatically redirected to your federation endpoint.  If IWA is working you will silently log in to ADFS and be returned to the MyApps site with a claim token and be presented with your authenticated home page.  The user never sees anything except the redirects working before ending up at the destination.
Other HRD acceleration methods are documented at https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-authentication-for-federated-users-portal
Dave Loder-- dloder.blogspot.com --


show

kool posted this 3 weeks ago

David, my concern is only with ADFS. Azure/O365 is just one of its relying parties. I know how home realm discovery works in Azure but that is irrelevant to my concerns, it was just an example of one RP. All of our ADFS RPs have the ClaimsProviderName

property set to our SAML IdP claims trust provider. It is clear to me now that this configuration prevents IWA from happening. Ideally ADFS could see that the user’s workstation is domain joined and has a valid TGT so it could silently bypass the SAML IdP.

I can see how this would be challenging to implement because then the claims rules either couldn’t rely on any of the SAML IdP attributes or it would need the ability to substitute an equivalent AD attribute rule. It would up the complexity significantly but

would still be a cool feature.

 

BTW, AAD’s use of email address as the user identifier for locating home tenant is problematic. AAD used to allow any self-asserted domain suffix for user email addresses and many other Internet IdPs still allow that dubious practice, but

that is another argument for another time.

 

    Eric

 

show

barkills posted this 3 weeks ago

AAD used to allow any self-asserted domain suffix for user email addresses

[BA] It did? When was that? I know it didn’t circa 2012, we didn’t allow the broad set of self-asserted email addresses in our AD at the time to move into Azure AD . Instead we reset every email address in our AD rather than add 360+ accepted domains to our tenant (as far as I know, having an accepted domain registered in your tenant has always been required to use any given domain as an email address). 2013 was when the term “Azure Active Directory” was first introduced, so that was pretty darn early.

Close