How to Secure Hybrid Office 365 Authentication

Posted on by Russell Smith in Cloud Computing, Office, and Office 365

Office 365 hybrid authentication lets organizations manage and control authentication to Office 365 using on-premise Windows Server Active Directory. The advantage is that there is a single set of user identities that can be centrally managed, as opposed to using cloud-only identities for Office 365 and Active Directory accounts for access to on-premise resources.

Traditional wisdom has it that Active Directory Federation Services (ADFS), or a third-party identity provider, is the most secure way to extend Windows Server Active Directory (AD) to Office 365. There are definitely some advantages to this approach, including:

  • Single sign-on for browser apps and Outlook.
  • No synchronization of password hashes to the cloud.
  • Advanced security features like IP address filtering.
  • Supports other SAML-based cloud services.
  • Supports SmartLinks.
  • Smartcard-based authentication.
  • Supports third-party multifactor authentication.

But the costs are great. Not only do you need a two-server farm, preferably at separate sites for redundancy but also another couple of servers should be placed in your DMZ to securely publish ADFS to the Internet. This involves additional infrastructure and cost, but it also adds extra points of failure. If ADFS, AD, or the DMZ servers go down, users won’t be able to access Office 365. Although, it is possible to combine ADFS with Password Hash Synchronization (PHS) so that users can still log in to Office 365 in the event of a problem.

Who’s Afraid of Password Hash Synchronization?

The idea of synchronizing password hashes to the cloud seems like a scary idea for some organizations. But is it really that bad? If you don’t trust Azure AD to be the guardian of your Office 365 data, then you’ve already got a problem. You need to decide whether Azure AD is up to the job of securing sensitive data in the cloud. Azure AD can be vulnerable to brute-force and password spray attacks through remote PowerShell, but this can be mitigated by enabling multifactor authentication (MFA) and disabling access to remote PowerShell for some or all users.

When AD Connect is configured to synchronize password hashes from AD to the cloud, SHA256 password data is stored in Azure AD, which is a hash of the MD4 hash stored in on-premise Active Directory. So the password hashes in Azure AD are more secure hashes of your on-premise AD password hashes. Or in other words, hashes of hashes. Furthermore, the SHA256 hashes in Azure AD cannot be used in Pass-the-Hash (PtH) attacks against your on-premise AD.

PHS gives users seamless single sign-on access to Office 365 regardless of whether ADFS and on-premise AD are accessible, which can be handy in an outage. It is also simpler to set up than federated authentication or Pass-Through Authentication (PTA), both of which require some onsite infrastructure. PHS fully supports Microsoft’s Azure AD defense technologies, like Azure Password Protection and Smart Lockout.

For more information on custom banned password lists (Azure Password Protection) and Smart Lockout see Azure AD Password Protection to Prevent Password Spraying Attacks on Petri. Here can find more details on Azure AD Conditional Access.

Federated Authentication versus Password Hash Synchronization

If you are planning an Office 365 deployment or reviewing existing security strategies, I recommend looking at Password Hash Synchronization first. It could simplify your infrastructure, reduce costs, improve availability, and even make you more secure in the long run. But that’s not to say that federated authentication and Pass-Through Authentication don’t have their places. Just don’t rule out PHS until you’ve evaluated it properly.




Don't have a login but want to join the conversation? Sign up for a Petri Account