Single sign-on (SSO) plays a key part in providing a secure authentication solution. However, the architecture and authentication flow of these solutions are paramount in ensuring that your identity broker retains its availability and integrity. IAM makes up a core component of the NCSC Cloud Security Principles. Therefore, when implemented it is important that the correct solution has been deployed to make sure it meets all the needs of the business and addresses risks in an appropriate manner. This article will highlight the above topic in relation to ADFS and Azure AD Connect.
Active Directory Federation Services (ADFS) is a SSO solution which complements applications which do not support integrated Windows Authentication. Often, ADFS is used as a means of providing Active Directory based SSO functionality to applications.
We regularly see ADFS used as a means of providing SAML-based services. However, many organisations also use this technology to provide authentication to specific domains when using services such as Microsoft 365.
The downside of ADFS is the overhead in ensuring availability during an outage. If Microsoft 365 is only configured to use ADFS then during downtime users cannot immediately authenticate without reactive activity being applied to each account to ensure authentication can be configured via Azure AD/Cloud Managed authentication.
NCSC guidance around this area is to use Cloud-Native authentication for Microsoft 365/Azure AD based services. This relates to “Seamless SSO with Password Hash Sync”. NCSC also suggest that:
“Federated authentication is recommended to be disabled as an authentication method to M365 and instead use Password Hash Sync (PHS). This is because on-premises AD Domain Services and ADFS infrastructure has been frequently targeted and compromised by threat actors with well documented methods of attack, specifically SolarWinds breach, Primary threat vectors from compromised on-premises environments”.
See: https://www.ncsc.gov.uk/blog-post/securing-office-365-with-better-configuration
PHS allows Azure AD to use a one-way hash to authenticate users, therefore not sharing any cleartext passwords with domain controllers. For more information on this technology see: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs.
The main advantage with this approach is that the availability of Microsoft 365 will no longer be affected by your on-premises ADFS or ADDS infrastructure. The logic behind this guidance is that access control is already being defined and controlled by Azure AD, whether this is via a Conditional Access policy, enforcing MFA to specific cloud apps, or just access control with services such as AAD Group membership.
The alternative (which does carry reliance on traditional active directory) is pass-through authentication. This form of authentication relies on an on-premises agent which Azure uses to validate authentication; Azure AD is not involved in validating user credentials. The advantage with this solution is that user-account states, password policy changes and sign-in hours can all be enforced immediately as there is no reliance on an AD Connect sync to update the AAD authentication. An example of this benefit could be a disgruntled employee who has their account locked out on-premises immediately to avoid misuse. With password hash sync there will be a short period of time (between syncs) where said employee can potentially authenticate into Microsoft 365 before their account is deactivated. This problem is non-existent when using pass-through authentication as the authentication flow always relies on traditional domain controller verification.
It is our recommendation to try and move away from using federated authentication for M365. This may seem like a difficult task however Microsoft have made it much less painful with the ADFS migration toolkit and the new ability to stage Cloud-Managed Authentication to specific groups of users. See: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-staged-rollout
Premium Azure AD functionality, including Identity Protection and Azure AD Domain Services, rely on Password Hash Sync being enabled, therefore it is suggested that PHS should at a minimum be configured as a backup solution for your primary authentication method. This should be considered a mandatory action when looking at ADFS. As previously mentioned, if ADFS were to go offline following an incident, then without PHS previously being enabled, administrators would first need to flip the domain to become cloud-managed, but also reset the password of every user which needs access to Office 365. With PHS being previously enabled, simply flipping the domain over is all that is needed to allow Azure AD to handle authentication to Office 365.
Notice that I have specifically mentioned users and not administrators; this is important as it is considered very bad practice to grant AD synchronised users any administrative rights in Azure AD due to the risk of lateral movement into Office 365/AAD if an account is compromised on premises. Thus only “onmicrosoft” accounts should be used when administering AAD/365.
Of course, the bigger picture, and the aim in the long term, should be to move away from ADFS entirely, considering Microsoft’s Zero Trust by “modernising” access via Azure AD, Cloud App Security and Application Proxy ensuring that the decentralised workplace is protected by an identity based, secure access solution.