Azure Pass Through Authentication AD

When requesting access to Azure resources, you can leverage your own corporate AD credentials.

To make this work, you have to setup pass through authentication (or full sync, which is not covered in this post).

Decision Tree

 

A confusing note from Microsoft’s Azure Docs

Note: As a pre-requisite for Pass-through Authentication to work, users need to be provisioned into Azure AD from on-premises Active Directory using Azure AD Connect. Pass-through Authentication does not apply to cloud-only users.

Why is this confusing?

If you are simply passing users through to AD, why do you even need users in Azure AD? Conversely, If you already have user identities synced to Azure AD, why do you need pass through authentication?

The answer is that even though users are synced across, their passwords are not.

How does this work? (Kerberos Tickets and Domain Hints)

1. To use cloud-based services, the user identity needs to existin in Azure AD. To use on-premises services, the identity needs to exist on-premises.  Thus, all accounts (identities) are actually duplicated between on-premises and Azure AD.  Minus the password.
2. Therefore, the password is not stored in Azure AD and Azure AD defers to the on-premises environment to perform the authentication.
3. Seamless SSO uses the securityIdentifier claim in the Kerberos ticket to look up the corresponding user object in Azure AD.
4. If an application (for example, https://myapps.microsoft.com/contoso.com) forwards a domain_hint (OpenID Connect) or whr (SAML) parameter – identifying your tenant, or login_hint parameter – identifying the user, in its Azure AD sign-in request, users are automatically signed in without them entering usernames or passwords.

What about SSO? (Azure AD Connect)

You will need another Azure component – Azure AD Connect (AAD Connect) – to make SSO work. Seamless SSO relies on AD Connect. In addition, you get the advantage of failing over to AAD if your on-prem AD is ever down (see below)

Seamless SSO – can be enabled via Azure AD Connect.

What are the limitations?

• Any app that needs to work with this scheme has to be on the latest Windows Identity Framework (asp.net 4.5.2 and above)
• It does not apply to cloud only (Azure only) users

Azure AD as a Failover for on prem AD

Enabling Password Hash Synchronization gives you the option to failover authentication if your on prem AD is down.

• This failover from Pass-through Authentication to Password Hash Synchronization is not automatic.
• You’ll need to switch the sign-in method manually using Azure AD Connect. If the server running Azure AD Connect goes down, you’ll require help from Microsoft Support to turn off Pass-through Authentication.

What is Seamless SSO? And what does it require?

Seamless SSO requires Azure AD connect and full sync (identities including Passwords).  SSO will work for native Azure apps (O365 etc.).

What about SSO for external SaaS Apps  – Blackboard for Example

If Blackboard SaaS was provisioned from the Azure Marketplace to begin with, here are the steps to ensuring that SSO works with it.

https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/blackboard-learn-tutorial

I already did this – but users get prompted over and over again for their credentials (not really SSO, is it?)

If you have password hash sync – this  could happen. If you have true pass through setup with Seamless SSO, this should work without re prompting for credentials.

What about EXTERNAL organizations that need to authenticate against on prem AD? – Answer – Extend your on-prem ADFS to Azure

Replicate an Active Directory Federation Services (AD FS) deployment to Azure, to perform federated authentication and authorization for components running in Azure.

Typical uses for this architecture:

• Authenticate and authorize users from partner organizations.
• Allow users to authenticate from web browsers running outside of the organizational firewall.
• Allow users to connect from authorized external devices such as mobile devices.

Benefits

• You can leverage claims-aware applications.
• Provides the ability to trust external partners for authentication.
• Compatibility with large set of authentication protocols.

Challenges

• You must deploy your own AD DS, AD FS, and AD FS Web Application Proxy servers in Azure.
• This architecture can be complex to configure.

What about Password Write back from AAD to On-Prem AD?

This is definitely possible – and it has two steps (each with a few sub steps):

•   Enable Password Writeback option in AAD Connect (need to be Global Admin to do this)
•   Enable password Writeback option in SSPR (need to be global admin to do this)

Summary

The only purpose of using pass-through authentication is being able to use both cloud and on-premises applications with a common password. It does not forgo identity sync across on-prem to Azure. In fact, AD to Azure AD identity sync is a requirement for pass through authentication to work. Also, password writeback to on prem AD is possible,