During our projects to support customers in their cloud journey, one of the first point of discussion is always related to the authentication method they should use to keep user credentials safe outside the well-known network perimeter.
Authentication is the foundation for cloud access and the Accounts and Access Management is the new security perimeter of the Cloud Era: choosing the right authentication method is a crucial decision, but also one that can be different for every organization and might change over time.
In this post, we will have a look to the different options on the table when you decide to embrace the Microsoft cloud solutions.
In a simple sentence, There are really two options for authentication in a Microsoft hybrid environment, no matter how complex your organization: you can choose to authenticate in the cloud or you can authenticate on-premises.
Cloud Authentication is the easiest and more secure option: there are a couple methods that Microsoft offers in Azure Active Directory (Azure AD).
The first one is called Password Hash Sync.
In this method, a hash value of the user’s password is extracted and synchronized in Azure AD to authenticate the user when they sign in from the cloud. They can use the same username and password from the on-premises environment to access cloud resources too. This should be really clear: Passwords are never stored in clear text or encrypted with a reversible algorithm in Azure AD.
Password Hash Sync doesn’t require to deploy any additional infrastructure to make it work in the cloud. This method also enables Azure AD Identity Protection capabilities, which protect and monitor your users’ passwords against leaked credential reports to prevent bad passwords from being used.
There are, of course some limitations: currently, password hash synchronization doesn’t immediately enforce changes in on-premises account states. In this situation, a user has access to cloud apps until the user account state is synchronized to Azure AD. Also the password expired and account locked-out states aren’t currently synced to Azure AD with Azure AD Connect: it means that the account on-prem can be locked but the user is still able to access the cloud services.
Most of the time this is our recommendation for small/medium customers with really simple requirements and limited IT support but, as I said at the beginning, it really depends of the organization.
The second one is Pass-through Authentication.
This method uses a software agent to connect to passwords stored on-premises for validation, so that users can sign in to cloud apps with the same username and password for on-premises resources. You need to install one or more (recommendation is three) agents on existing servers (they could be your DCs): they must have access to your on-premises Active Directory Domain Services.
From an IT prospective, Pass-through authentication is lightweight and does not store any form of user passwords in the cloud, which may be a requirement security reasons (even if hash is not reversible) or compliance.
Pass-through authentication is working seamlessly with Azure AD conditional access policies and Identity Protection (almost..) and it also supports Smart Lockout to prevent brute force attacks.
One of the best options in my opinion is that Pass-through authentication can be enabled as primary authentication methods and Password Hash Sync as secondary: it means that, in case your datacenter will go offline (external network connectivity lost for example), you will be always able to access your cloud services.
Obviously, we have limitations also here: Organizations that require multi-factor authentication with pass-through authentication must use Azure Multi-Factor Authentication (MFA). Also it only supports cloud apps that use modern authentication and specific (and old) Exchange Online protocols and Agents servers should be able to reach internet on port TCP 443 with HTTPS protocol.
Advanced features require that password hash synchronization is deployed whether or not you choose it or not as backup authentication method: an example is the leaked credentials report of Identity Protection.
Pass-through authentication is becoming in our projects one of the most chosen (and my preferred one) because of it’s flexibility in terms of business continuity, integration with the Microsoft Cloud Security ecosystem and simplicity to deploy but, sometimes, the requirement to use external MFA system is a no-go.
With Federated Authentication, Azure AD will hand off the authentication process to a separate trusted authentication system, such as Active Directory Federation Services (ADFS) or PingFederate (that is also included in the wizard of the latest Azure AD Connect). This method makes sense for organizations with authentication requirements not currently available in Azure AD, such as legacy application protocols, sign-in requirements (sAMAccountName instead of User Principal Name), or smartcards/certificates authentication.
From an IT Prospective, this is the most complex scenario you have to deal with: the maintenance and management of the federated system falls outside the control of Azure AD. It’s up to the IT Support to make sure it’s deployed securely and can handle the authentication load.
Here the limitations are not related with functionalities (it’s your On-Prem federated system – you can do whatever you decide with it) but in terms of business continuity, security, governance and maintenance.
In our projects, this solution is chosen mostly by companies that want to reuse their existing federated system investment with their Azure AD hybrid identity solution even is it requires significant investment in on-premises infrastructure. The flexibility of this solution can anyway pay back this costs.
So, in the end?
As this article outlined, there is no silver bullet (and go away from anyone who’s saying that!) for authentication solution during the project: the important thing here is to know feature and limitations of any of of them and always understand that you can start with one that fits best at the moment and change it later if the requirements are evolving.