1. Choosing the right authentication method for Azure Active Directory
6/29/2019
Choosing the right authentication method for Azure Active Directory
Azure Active Directory Customer Success Team
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

2. Agenda Azure Active Directory (Azure AD) Connect
6/29/2019
Agenda
Azure Active Directory (Azure AD) Connect
What are your authentication options in Azure AD?
Recommendations
Resources
Q & A

3. Azure AD Connect: Your identity bridge
6/29/2019
Azure AD Connect
(provisioning and sign on)
Active Directory
Single sign-on (SSO)
SaaS = Software as a service
User
Device

4. Federated authentication
What are your authentication options in Azure AD?
6/29/2019
Cloud authentication
Cloud-only
Password hash sync and Seamless SSO
Pass-through authentication and Seamless SSO
Federated authentication
Active Directory Federation Services (AD FS)
Third-party federation providers
Azure AD support many authentication methods to help meet our different customers’ requirements.
The options range from very simple to support new, so called “born in the cloud” organizations to large multi-national organizations with complex authentication requirements
The first option is cloud-only accounts. In this option you create and maintain user identities in Azure AD and Azure AD handles the authentication completely.
All of the other options are for organizations with existing on-premises Active Directory. We call this hybrid identity.
The second option is Password Hash Sync . This allow your users to sign in to cloud apps and on-premises apps using the same password they use with Active Directory today. Azure AD is the source of authentication for users, so users enter their username and passwords in Azure AD. No additional infrastructure need to be deployed besides Azure AD Connect (our provisioning tool) on-premises for this option to work. This option also protects your user’s passwords in the cloud. More about this later
The third option is Pass-through authentication. This is similar to Password Hash Sync, but is a great option for organizations with strong security and compliance policies.
The last two options use federation, using either Microsoft’s AD FS solution or a third party federation providers that are compatible with Azure AD. When you choose this authentication method Azure AD will hand off the authentication process to a separate trusted authentication system, such as AD-FS, to validate the user’s credentials and sign them in. As we shall see, this option makes sense for customers with authentication requirements that are not currently available in Azure AD.
This might seem like a hard decision, but we will break this down for you in this presentation.

5. Identity sync with password hashes
Password hash sync
Cloud
On-premises
SaaS
Public cloud
Azure
Azure AD
App access
User
Azure AD Connect
🔑 User sign-in
Identity sync with password hashes
Functional
Password Hash Sync is our recommended option and gives you the simplest, lowest cost, and highest availability cloud authentication for your users. The only on premises dependency is Azure AD Connect, which is the connect point between your on premises environment and Azure AD.
Technical (only if customer asks)
The way this works is fairly simple:​
​You first install Azure AD Connect, our provisioning tool. It provisions your on-premises users and establishes their identities in Azure AD. You can also use it to enable the password hash sync option.​
<Note. Always emphasize we never deal with clear text passwords>
​On-premises AD stores passwords in hashed form. A hash is a result of a one-way mathematical function, called a hashing algorithm. ​The clear text password cannot be reversed from its hashed form.
​To provide sign-in in the cloud, Azure AD Connect reads those password hashes from Active Directory, and hashes them again a 1000 times, before it is coping to Azure AD. It does this every 2 minutes. ​
​Remember, there is NO way to get the original password from the hash and nothing is ever stored in clear text.​
​When the user wants to sign-in to a cloud application, he is redirected to Azure AD to sign in. The user will then provide a username and password.​
​Azure AD will do the same hashing algorithms on the input password and if the resulting hash value matches the stored value in Azure AD, then the user is signed in and will get access to the application. ​
During authentication there is no dependency on any on-prem infrastructure– users are authenticating directly to Azure AD. ​
Potential customer question: I really like Password Hash Sync, but I have one more concern. If they use it, does this mean users will have to type their username and password for every cloud app they want to access?
No, customers can and should implement a feature called Seamless single sign-on. This feature creates the necessary permissions in your on-premises AD to seamlessly sign users in to accessing apps and resources without prompting them for credentials. Let me tell you how it works
Directory query
Least complex
Lowest on premises footprint
Highest availability
Active Directory

6. Pass-through authentication
Cloud
On-premises
SaaS
Public cloud
Azure
Azure AD Connect
Identity sync
Directory query
Pass-through authentication agent
Azure AD
App access
🔑 Pass-through authentication
User
Active Directory
🔑 User sign-in
Pass-through authentication agent
Functional
Pass-through authentication is also a recommended authentication method. This option is simple and maintains a minimal on premises footprint. This method installs an agent on premises that makes an outbound persistent connection to Azure AD to listen to authentication requests. The agent validates username and password against Active Directory, so all users are signing in directly to Azure AD, but authentication is happening through the agent against your on premises AD. You must install at least two lightweight agents on premises for high availability.
Technical (only if customer asks)
Pass-through authentication is also setup using Azure AD Connect just like with Password Hash Sync.
But instead of syncing password hashes to the cloud we deploy 2, or more pass-through authentication agents on-premises. These agents will make outbound persistent connections to Azure AD and listen for authentication requests.
So when a user tries to sign in to Azure AD the user enters their username and password into the Azure AD sign in page. Azure AD places the username and password, encrypted using a public key, on a queue in the cloud.
One of the agents retrieves the username and encrypted password from the queue. The agent decrypts the password using its private key.
The agent validates the username and password against Active Directory. The appropriate response (success, failure, password expired, or user locked out) is returned to Azure AD via the agent. If the user sign-in is successful, the user can access his or her application.
Pass-through authentication also supports smart lock out, but doesn’t support password protection. Pass-through authentication can be combined with Seamless SSO for the best possible user sign-in experience.
Less complex
Less on premises footprint

7. Federated authentication
SaaS
Public cloud
Azure
Cloud
Perimeter
On-premises
Azure AD Connect
Identity sync
Azure AD
App access
Directory query
User
🔑 User sign-in
Active Directory
🔑 Validation
Federation proxy
Federation server
Functional
Federation through AD FS is the final way to set up authentication with Microsoft. This is the most costly and complex, with all maintenance and deployment performed by you, the customer. As you move to the cloud, deploying more on premises infrastructure does not usually make sense. We only recommend this option in specific scenarios where Password Hash Sync and Pass-through Authentication do not meet your requirements. We will talk about some of those in the next slide.
Technical (only if customer asks)
Federation requires more servers. First we have to deploy 2 or more federations servers internally to accept authentication request. More than one is required for high availability and disaster recovery.
Next you will require 2 or more servers in your perimeter/DMZ network, called web application proxy servers. They relay authentication request from the Internet to the internal AFDS servers.
When a user needs to access a cloud app, Azure AD will redirect the users app to the federation proxy servers to authenticate, which will in turn send the request to the internal ADFS server. The internal ADFS server will paint the sign-in screen, accept the username and password as input, and validate passwords against the internal domain controllers.
This basic topology can be expanded to support other scenarios such as MFA servers, smart card authentication. And it works well to add custom claims we want to impose on the user for authorization purposes.
Federated authentication is not just ADFS, but we also support other 3rd party providers and we publish a list of officially supported providers.
Moving to cloud, but having to deploy tons of on prem infra. Doesn’t make sense unless you already have it and you fit the criteria on next slide.
🔑 User sign-in redirection
Federation server
Federation proxy
Most complex
Highest on premises footprint

8. Recommendations No real-time on-prem dependency
TechReady 23
Recommendations
6/29/2019 6:06 PM
No real-time on-prem dependency
Leaked credential protection
1st
Password Hash Sync + Seamless SSO
Disaster recovery
Leaked credential protection
Pass-through Authentication + Seamless SSO
2nd
Pass-through Authentication + Password Hash Sync + Seamless SSO
Disaster recovery
Leaked credential protection
In this order, we recommend:
PHS
PTA
ADFS
Regardless of which you choose as primary auth method, we recommend the above configurations to ensure you get the most benefit.
If you choose ADFS and have EMS E3 or AADP1 or higher, we recommend turning on ConnectHealth for additional data insights and benefits already included in your AADP licenses
3rd
*When choosing federation using Active Directory Federation Services (AD FS), Microsoft recommends deploying Connect Health, an Azure AD Premium feature.
Federation*
Federation + Password Hash Sync
© 2016 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

9. Performance monitoring
TechReady 23
Azure AD Connect Health for AD FS
6/29/2019 6:06 PM
Monitor and gain insights into your on-premises identity infrastructure
Alerts
Monitor health of identity servers and receive alert notifications in
Usage analytics
Analyze with different pivots like app, users, and network location
Performance monitoring
View performance data trends and sync operational insights.
Reporting
Reports about on-going activities on your identity servers
Requires Azure AD Premium 1 or greater, EMS E3 or greater, or Microsoft 365 E3 or greater licensing.
© 2016 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

10. Pass-through authentication
Authentication method comparison
6/29/2019
Password hash sync
Pass-through authentication
Federated
Level of effort
Low effort: Setup using Azure AD Connect
Low effort: Agent deployment with outbound internet connectivity only
High effort: AD FS farm, proxy farm, DMZ, certificates
SSO and multi-factor authentication (MFA)
Cloud: Seamless SSO, Azure MFA
On premises: AD FS Windows Integrated Authentication (WIA), Azure MFA or MFA Server
Advanced scenarios
Unlocks cloud security capabilities: Leaked credentials, risky sign-ins, Smart Lockout, block legacy authentication, Azure AD SSO
Hybrid benefits: Enables on-premises account policies in the cloud, risky sign-ins, Smart Lockout, block legacy authentication, Azure AD SSO
Needed for some advanced scenarios:
Sign-on using smartcards or certificates, sign-on using on-premises MFA Server,
multi-site on-premises authentication solution
Business continuity
Built into Azure AD due to authentication directly to the cloud
Deploy multiple agents or use password hash sync as a backup
Requires load balancers, multiple servers,
use password hash sync as backup
Other considerations
Delays in replicating account state to the cloud
On-premises dependency during authentication
Password Hash Sync
Functional
Password Hash Sync is our recommended option and gives you the simplest, lowest cost, and highest availability cloud authentication for your users. The only on premises dependency is Azure AD Connect, which is the connect point between your on premises environment and Azure AD.
Technical (only if customer asks)
The way this works is fairly simple:​
​You first install Azure AD Connect, our provisioning tool. It provisions your on-premises users and establishes their identities in Azure AD. You can also use it to enable the password hash sync option.​
<Note. Always emphasize we never deal with clear text passwords>
​On-premises AD stores passwords in hashed form. A hash is a result of a one-way mathematical function, called a hashing algorithm. ​The clear text password cannot be reversed from its hashed form.
​To provide sign-in in the cloud, Azure AD Connect reads those password hashes from Active Directory, and hashes them again a 1000 times, before it is coping to Azure AD. It does this every 2 minutes. ​
​Remember, there is NO way to get the original password from the hash and nothing is ever stored in clear text.​
​When the user wants to sign-in to a cloud application, he is redirected to Azure AD to sign in. The user will then provide a username and password.​
​Azure AD will do the same hashing algorithms on the input password and if the resulting hash value matches the stored value in Azure AD, then the user is signed in and will get access to the application. ​
During authentication there is no dependency on any on-prem infrastructure– users are authenticating directly to Azure AD. ​
Potential customer question: I really like Password Hash Sync, but I have one more concern. If they use it, does this mean users will have to type their username and password for every cloud app they want to access?
No, customers can and should implement a feature called Seamless single sign-on. This feature creates the necessary permissions in your on-premises AD to seamlessly sign users in to accessing apps and resources without prompting them for credentials. Let me tell you how it works
Seamless SSO
You should combine Password hash sync or Pass-through Authentication with Seamless SSO. Seamless SSO automatically signs users in when they are on their corporate devices connected to your corporate network. When enabled, users don't need to type in their passwords to sign in to Azure AD.
This feature is also setup using Azure AD Connect.
Pass-through Authentication
Pass-through authentication is also a recommended authentication method. This option is simple and maintains a minimal on premises footprint. This method installs an agent on premises that makes an outbound persistent connection to Azure AD to listen to authentication requests. The agent validates username and password against Active Directory, so all users are signing in directly to Azure AD, but authentication is happening through the agent against your on premises AD. You must install at least two lightweight agents on premises for high availability.
Pass-through authentication is also setup using Azure AD Connect just like with Password Hash Sync.
But instead of syncing password hashes to the cloud we deploy 2, or more pass-through authentication agents on-premises. These agents will make outbound persistent connections to Azure AD and listen for authentication requests.
So when a user tries to sign in to Azure AD the user enters their username and password into the Azure AD sign in page. Azure AD places the username and password, encrypted using a public key, on a queue in the cloud.
One of the agents retrieves the username and encrypted password from the queue. The agent decrypts the password using its private key.
The agent validates the username and password against Active Directory. The appropriate response (success, failure, password expired, or user locked out) is returned to Azure AD via the agent. If the user sign-in is successful, the user can access his or her application.
Pass-through authentication also supports smart lock out, but doesn’t support password protection. Pass-through authentication can be combined with Seamless SSO for the best possible user sign-in experience.
ADFS
Federation through AD FS is the final way to set up authentication with Microsoft. This is the most costly and complex, with all maintenance and deployment performed by you, the customer. As you move to the cloud, deploying more on premises infrastructure does not usually make sense. We only recommend this option in specific scenarios where Password Hash Sync and Pass-through Authentication do not meet your requirements. We will talk about some of those in the next slide.
Federation requires more servers. First we have to deploy 2 or more federations servers internally to accept authentication request. More than one is required for high availability and disaster recovery.
Next you will require 2 or more servers in your perimeter/DMZ network, called web application proxy servers. They relay authentication request from the Internet to the internal AFDS servers.
When a user needs to access a cloud app, Azure AD will redirect the users app to the federation proxy servers to authenticate, which will in turn send the request to the internal ADFS server. The internal ADFS server will paint the sign-in screen, accept the username and password as input, and validate passwords against the internal domain controllers.
This basic topology can be expanded to support other scenarios such as MFA servers, smart card authentication. And it works well to add custom claims we want to impose on the user for authorization purposes.
Federated authentication is not just ADFS, but we also support other 3rd party providers and we publish a list of officially supported providers.
Moving to cloud, but having to deploy tons of on prem infra. Doesn’t make sense unless you already have it and you fit the criteria on next slide.
Other ADFS Info
Some organizations may require a authentication feature not currently supported by Azure AD natively. For example, you may want to do Smart card authentication or integrate with an existing on-premises MFA server. These organizations should use federation.
Keep in mind as Azure AD evolves quickly and we add new features all the time. So make sure you check our latest documentation when you make this decision.
Multi-site on-premises authentication solution: I.E. Do you have an existing ADFS farm that spans continents? Do you want to do this yourself or have Microsoft manage this for you?
If yes, then probably keep ADFS unless willing to migrate
If no, Azure AD (Password Hash Sync or Pass-through Authentication) provides globally available authentication
Smart lock out in PHS and PTA vs. AD FS External lock out

11. Resources Azure AD webinars Resources
TechReady 23
Resources
6/29/2019 6:06 PM
Resources
Choosing the right authentication method
Migration guides
Video
Deployment wizard
More info on how Password Hash Sync works:
Azure AD webinars
© 2016 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

12. 6/29/2019
Q & A

13. 6/29/2019
Thank you!
© 2019 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.