20190904: Entra ID Password Hash Sync analysis

Last updated: November 15, 2023
Audience: IT Staff / Technical

Password Hash Sync for UW Entra ID uw.edu domain

This document provides analysis about UW use of the Entra ID password hash sync option.

Contents
Executive Summary
Background
           Table 1 – Primary authentication options for Entra ID
Assumptions
Discussion
           Fallback
           Primary
                                 Table 2 – Important Characteristics of PHS vs Federated for primary authentication
                      Diluted legitimacy
                      User Experience for PHS
Recommendation
Actionable Feedback
Reference material

Executive Summary

Enabling Entra ID Password Hash Sync as a fallback option has many upsides, no downsides, and is a blocker to provide a key solution for customer hybrid cloud scenarios.

Enabling Entra ID Password Hash Sync as the primary authentication option is a compelling choice which would allow us to simplify our existing architecture at the cost of changing the user experience. This is an excellent option to implement in concert with the Entra ID/Office 365 MFA project.

Background

There are many different integration architectures for Entra ID. 

One primary integration characteristic is how user identities are provisioned. Most customers use synchronization from on-premises–primarily from AD–while some customers have an Entra ID native process.

Another integration characteristic focuses on the primary authentication method for user identities. The options include: 

  • Entra ID native – password stored/managed in Entra ID
  • Federated – password stored/managed in AD or another customer controlled system
  • Password hash sync – password hash synchronized/password managed from AD
  • Passthru authentication – password sent from Entra ID to AD via an agent for verification

Table 1 – Primary authentication options for Entra ID

Entra ID native Federated Password Hash Sync Passthru AuthN
Password storage Entra ID UW UW UW
Password Mgmt Entra ID UW UW UW
Pwd compromise alerting Yes No Yes No
User interface Entra ID UW Entra ID Entra ID
Viable fallback No No Yes No
Needed for AAD-DS Yes No Yes No

Among those options, the password hash sync (PHS) is unique in that it can be pre-configured & provisioned so that if your preferred authentication method fails or has significant issues, you can quickly fall back to PHS as the preferred method.

Both the Entra IDnative and PHS options have a significant benefit in that Microsoft checks user accounts (with these methods configured) for known compromised credentials. If found, Microsoft raises a security alert (and can automatically disable, if desired).

Entra IDnative, PHS, and Passthru result in the Microsoft Azure logon prompt user experience. Federated results in whatever user experience is associated with your federated IdP, which in our case is Shibboleth (via ADFS).

Some Microsoft product features do not work with specific primary authentication methods. For example, Entra ID Domain Services, a feature that has been determined is needed by UW customers, can not be enabled without either having Entra ID native or PHS enabled. The existing UW configuration prohibits use of Entra ID Domain Services, and minimally, we’d need to enable optional PHS.

Microsoft has an Entra ID based self-service password reset (SSPR) capability, which is capable of working with all of the primary authentication methods.

Assumptions

  • Microsoft security protections for password hash sync are sufficient for UW concerns.

    A password hash is not a password; a password hash is a one-way transformation of the password that given the hash can not be reversed to produce the password. Possession of a hash does not mean you know or can derive the password upon which it is based.

That said, a password hash does have some sensitivity. You can run any given string through the same hash algorithm to see if that string matches the password hash; if it does, you know the password. So possession of the hash does mean you have an ability to brute-force passwords. If you were able to steal the hash without being known, you might circumvent any brute-force mitigations in place. However, the likelihood of stealing hashes within the Microsoft PHS process appears very low, given their data handling description and extensive certifications.

  • Our initial goals in enabling PHS are:
    • to allow for fallback should federated methods fail or have significant problems
    • get known compromised account alerts
  • We are open to the possibility that the Microsoft ecosystem benefits of using PHS as the primary authentication method outweigh the enterprise benefits of having fewer user authentication experiences
  • SSPR is not of interest because the UW has its own custom password management system.

Discussion

Fallback

As described in Background, there are clear benefits to enabling password hash sync as a fallback option. We also need to enable it if we are to pursue a separate goal of enabling Entra ID Domain Services. The costs of doing so are:

  • 2-3 day Entra ID Connect outage while a full sync is run. We’ve had such outages in the past and the impact on customers is low.
  • A very small risk that someone could steal password hashes and perform brute force on them to determine the passwords. In our estimation, this risk seems to be smaller than the risk that someone could steal the password hashes from our AD domain controllers, because of the superior operational security Microsoft has in place for Entra ID.

Given this, there’s no good reason to not enable PHS sync as a fallback option. Presuming we move forward with that, there are additional things to consider, such as creating a fallback implementation plan. But that is outside the scope of this analysis paper.

Primary

A less clear cut topic is whether password hash sync is better than federated authentication as the primary authentication method for UW’s Entra ID. A recent UW-IT project evaluating MFA solutions for Entra ID had 4 possible recommended solutions, 2 of which used PHS as the primary authentication method and 2 of which used federated authentication. The project stopped short of recommending only one of the four solutions, because there are a lot of factors that stakeholders may weigh differently than that project team.

Based on the prior work and pulling in a few details not in the published recommendations, here are the important & relevant points to consider:

  1. UW’s existing federated authentication architecture for Entra ID is complex. We’ve experienced many outages over the past 2 years directly related to the complexity. In most cases, we don’t understand the causes of those issues. We can continue with this approach, but we are likely to continue to experience outages as well as need highly technical expertise to support it.
  2. Switching to PHS as the primary authentication means that users will be expected to enter their UW NetID password in another interface. There are legitimate concerns about fracturing the trust users have in a single centrally-provided web authentication interface. However, there may already be plenty of other web authentication interfaces that users are putting their UW NetID password into.
  3. Microsoft provides the broadest technology feature support for Entra ID native & PHS methods. This is because these are the simplest authentication methods and are tightly integrated with Entra ID. If we want to maximize Microsoft feature support, choosing one of these methods is the best choice.
  4. Federated authentication gives us some control over the authentication user experience, including the ability to implement authentication features Microsoft doesn’t provide or are costly to purchase from Microsoft. At this time, there aren’t any features we want to provide that we aren’t already licensed for, so this is a mute point at this time, but we can’t predict the future.
  5. When paired with 2FA, there are some technologies which break:
    • Windows Hello for Business (WHfB) only works with PHS + Azure MFA. WHfB is the only password-less option Microsoft supports for Windows clients.
    • Legacy authentication (non-OIDC/OAuth compatible client) breaks with Federated + Duo when Duo is triggered by Shibboleth. This is only significant if we think there are scenarios where we want to enable 2FA for a user, but also allow a “back door” where they can avoid 2FA with a legacy client. This is unlikely, but some other universities do support these scenarios, so there may be political or other non-technical reasons to consider here.

Table 2 attempts to summarize these points into a slightly simpler form.

Table 2 – Important Characteristics of PHS vs Federated for primary authentication

PHS Federated
Supportability 👍👍 👎👎
Diluted Legitimacy 👎 👍
Future-proofing 👍👍 👍
Best capabilities 👍👍 👍
Non-labor costs $0 $47k
Labor costs $0 $40k
Prevent Breakage 👍 👎
User experience 👍? 👍
  • Supportability: How easy or hard is it to provide and support the products & systems in this approach? 
  • Diluted legitimacy: The perceived impact arising from users needing to enter a UW NetID password at a new URL and the possible security consequences, where users may be overly trusting of other new URLs that they should not trust.
  • Future-proofing: The perceived agility this authentication approach will have to new emerging capabilities and features
  • Best capabilities: In comparison with other possible authentication solutions, what is the perceived value of the capabilities possible with this solution?
  • Non-labor cost: How much does it cost the UW to provide this solution, in non-labor money?
  • Labor costs: How much does it cost the UW to provide this solution, in labor money?
  • Prevent breakage: Some capabilities don’t work with certain authentication solutions. This rates the relative breakage of the solution.
  • User experience: What is the perception of the user experience? Does it introduce problems or is it a seamless part of their expectations?

The trick is determining what relevance or weight to give to these characteristics. If, for example, MSCA is planning to discontinue support for legacy authentication in a few months, then the thumbs down under the Federated-Prevent Breakage cell is not important.

When comparing these characteristics, with the exception of diluted legitimacy, PHS is superior to Federated. The user experience characteristic is also unclear. 

If diluted legitimacy is very important, than Federated may be superior. So we should examine diluted legitimacy, to help determine how critical its impact is.

We should also take a look at the PHS user experience more closely to have a more informed opinion about its perceived impact.

Diluted legitimacy

UW-IT does not document locations that are trusted to enter your UW NetID password. This fact alone is partially informative in terms of how important this characteristic is. 

Since there isn’t a well-known source of this information, we need to do a bit of analysis on the common locations that UW populations may currently be entering their UW NetID password, and we’ll attempt to categorize these locations by how “trusted” or legitimate these locations are.

Trusted (or UW IAM promoted) UW NetID Password UIs:

  • Idp.u.washington.edu
  • “Windows logon prompt” for a computer that is AD joined to NETID
  • Unix logon for a computer that is joined to NETID AD or u.washington.edu Kerberos realm
  • Mac logon for a computer that is joined to NETID AD or u.washington.edu Kerberos realm

Marginally trusted (also promoted by UW-IT, but not necessarily by UW IAM) UW NetID Password UIs:

  • Web browser challenge/response for a web server using Integrated Windows Authentication with NETID
  • Windows based VPN interface leveraging NETID AD
  • 3rd party applications via LDAP proxy integration. There are at least several dozen integrated with NETID AD

Non-centrally provided UW NetID password UIs:

  • “Windows logon prompt” for a computer that is AD joined to AMC or another AD where the user namespace and password matches
  • Web browser challenge/response for a web server using Integrated Windows Authentication with AD other than NETID, where user namespace & password matches
  • UWM VPN leveraging AMC AD, where user namespace & password matches
  • Any SaaS app where the user chooses to use their UW email address as a username and their UW NetID password. While we don’t have direct evidence of frequency, there is general industry belief this is a prevalent user practice

So there are potentially a lot of UIs other than idp.u.washington.edu that UW populations enter their UW NetID password into today. Adding another may dilute the legitimacy, but it is hard to claim this is significant given the many other examples. A few of these examples might be replaced by more trusted UIs, if this was seen as a significant issue and prioritized.

In summary, given the current landscape, the diluted legitimacy does not seem significantly impactful, unless the other instances for concern have been ignored in terms of their importance, which seems unlikely.

User Experience for PHS

We’ll start by describing the default user experience, then cover ways in which we might customize it, and finally some analysis about the perceived impact.

The Entra ID authentication experience was generally documented in a change Microsoft made in 2017: https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/The-new-Azure-AD-Signin-Experience-is-now-in-Public-Preview/ba-p/245289. This document describes the public preview of that “paginated authentication” change, which was generally released in November 2017. As noted in the screen shots on that page, the username is collected on one page, then the password on a 2nd page. 

In our existing federated configuration, the user never sees the 2nd password page, because at that point they are redirected to ADFS, then redirected to the Shibboleth IdP, where they must again enter their username, and finally their password.

For PHS, the above Microsoft document closely describes the user experience. The customizations possible are also shown in that document. In general, there are two customizations possible:

  • Small logo and help/contact information added to the pages where users enter credentials. These customizations would be seen by all customers on the password page, and should be seen by all customers on the username page if tenant-specific links are used. These customizations would not be visible on the username page, if a non-tenant-specific link is used, because Microsoft doesn’t yet know that the user is from the UW.
  • Custom background screen shown for desktop users. This is the background behind the username and password frame, and is only present on non-mobile experiences.

Microsoft documents in detail the possible customizations here: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/customize-branding.

An example customized Entra ID logon is Yale’s:

Note that they’ve customized the background, added a logo (which is just the word Yale), and help text below.

Yale describes the reason behind their customizations as directly related to the change from federated authentication to PHS: “In your communication to users about the change, include screenshots of the above — the small credentials window with your logo and customized helper text on it and the larger screen such as what people would see in a web browser with the background image — and tell them that if they don’t see one of these views BEFORE they enter their password then they should stop and contact the helpdesk.”

In other words, Yale had legitimacy (or phishing) concerns regarding their change from federated to PHS, and used customizations to set user expectations about the trustability of the interface.

A minor issue for PHS that may affect the user experience is password change latency. AD password hashes are synchronized to Entra ID every 2 minutes. This slight delay may cause some frustration to the UW community which has a general expectation of nearly immediate password changes. However, overall this is unlikely to be  significant.

On the whole, there are some improvements to the user experience with PHS, with the user not needing to re-enter their username a 2nd time, and concerns about legitimacy and the transition addressed via customization. There is an impact to users of a new experience, but provided we manage that change with sufficient communication, the cost of that impact should be acceptable.

Recommendation

The UW should definitely proceed with enabling PHS (as a fallback to federated) to gain another fallback option and improved security insights, as well as meet the minimum requirement to enable Entra ID Domain Services.

Analysis also supports switching to using it as the primary authentication; the potential support problems and costs of continuing with a complex ADFS + Shibboleth architecture are very convincing motivation, with a small downside of making a user-impacting user experience change.

Actionable Feedback

  1. Add UW branding example for purposes of considering PHS as primary authentication option. Action item responsibility: Entra ID /O365 MFA project.
  2. Separate diluted legitimacy section into separate doc to allow this topic to continue to develop outside the PHS topic. Action item responsibility: UW IAM business service.

Reference material