cybureauocracy

the finer things of cyber

Remediating Users in Hybrid AAD/Entra ID Environments

Ethan Bowen
,

Did you know:

  • Active Directory [AD] Password Resets may not sync to Entra ID?
  • Kerberos tickets can still be used after a password change?
  • Password changes/resets in Entra ID may not revoke all a user’s sessions?

Me neither! That is why I wrote this post. I recently spent time investigating how Entra ID and AD can be used for user remediation.

Some of what I found is not what I assumed 🙂

What is Entra ID?

Entra ID is Microsoft’s cloud identity provider. Both Azure and Microsoft 365 [Exchange, Teams, SharePoint, etc.] use it for identity. When you login to SharePoint, you first authenticate to Entra ID, which in turn gives you tokens to access SharePoint. (Entra ID used to be called Azure Active Directory [AAD].)

Since most organizations use Azure/M365, they also must adopt Entra ID. However, this quickly leads to a problem: most organizations already have a primary identity provider in the form of on-premises Active Directory (AD).

What is Entra ID Connect?

In order to solve this problem (and increase adoption of MS cloud services), Microsoft created Entra ID Connect which provides identity synchronization between AD and Entra ID. The identities that exist in both places are usually called hybrid identities.

Entra ID Connect also provides different methods to handle authentication for these hybrid users. Some of these include:

While this sync is very nice for users, who enjoy a better sign-in experience, it creates more complexity for security teams. Tracking user investigations and remediation are now much more complex.

Let’s discuss in more detail.

How does the identity syncing work?

By default, AD is treated as the ‘golden source’. The identity is first created in AD. Then it is created in Entra ID and kept in sync by the Entra ID Connect agent. This agent is installed in your AD environment. Essentially, the agent does the following:

  1. Reads directory information using an AD account [e.g. MSOL_xxxxx].
  2. Writes it to Entra ID using a special Entra ID account [e.g. Sync_xxxxxx@<tenantdomain>.onmicrosoft.com].

By default, this sync process runs every 30 minutes. (Passwords are synced ~every 2 minutes.)

Below we’ll look at what happens after a user is created in AD.

First, my AD sync agent signs into Entra ID using its Entra ID account.

Next, the agent adds my user to the Entra ID directory and syncs certain properties (Name, MailNickname, UPN, etc.). These properties can be configured by your organization.

The picture below is from the Entra ID Audit logs and shows the properties and values.

Now Bilbo can login to Entra ID and start talking to Frodo on Teams.

We now know the basics of how this identity sync works. Let’s discuss the different options for how users can authenticate to Entra ID with these new hybrid identities.

Password Hash Synchronization (PHS)

PHS synchronizes the user’s password1 to Entra ID . This means Entra ID can authenticate the user on its own. Therefore, AD is not involved in this method. I assume this is the most common method, because it is simplest.

With PHS, your AD event logs have no sign-in records related to Entra ID2. Instead, the Entra ID sign-in logs must be reviewed.

Password Write Back (PWB)

Imagine a user is traveling for work and needs to change their Entra ID password. They are off the corporate network and therefore cannot see the Domain Controller. Since AD is the authoritative source, they cannot change their password.

Enter Password Write Back. This Entra ID Connect feature allows password changes in Entra ID to be written back to AD. It is required for features like Self-Service Password Reset (SSPR), which allows users to change their password in Entra ID if they have pass certain authentication checks.

This feature is not enabled by default, but is commonly used.

Pass-Through-Authentication (PTA)

PTA leverages Entra ID Connect and additional authentication agents to validate the password in AD when an Entra ID sign-in occurs. Microsoft has a good diagram:

Remediation Considerations

Microsoft has a good page on the basics of containing a user in AD/Entra ID: Revoke user access in an emergency in Microsoft Entra ID — Microsoft Entra ID | Microsoft Learn

However, I think it is more nuanced than described and the article does not explain enough about why some actions are required. I will add some more details and explanation.

Scenario
Let’s assume someone in Finance ran malware on their laptop. Of course, they’re a local admin, so who knows what happened. Let’s assume we use PHS and therefore their AD credentials (+Entra ID) are compromised. What should we do?

Disable the user in AD!

We usually think about is disabling their AD account, while the investigation kicks off. This limits lateral movement by stopping AD from issuing new3 Kerberos tickets or validating new NTLM requests.

Below, you can see the user legolas is disabled and the Domain Controller (DC) will not issue a new Service Ticket.

Additionally, if I try to use NTLM authentication the DC rejects it.

Great!4

But what happens in Entra ID…?
It can take up to 30 minutes for the user’s account to be disabled in Entra ID. This is due to the default Entra ID Connect synchronization interval! So while the attacker cannot get new accesses in AD, they can still login to Exchange, SharePoint, etc.

If you are sure an account is compromised, this delay is unacceptable. Therefore, you also must disable the account directly in Entra ID. This may require new permissions and updated workflows for your team.

Reset the password!

What if the user needs to continue working and disabling their account is not acceptable? Another option is an AD Password Reset.

This changes the user’s password + by default sets the “User must change password at next logon” flag in AD. (The last part is important later on.)

Kerberos Tickets remain valid

Even after a password change, the user’s existing Kerberos tickets (TGT/ST) are still valid. If an attacker stole your TGT + session key, they can use it to acquire new access until the TGT’s renewal period expires (1 week by default). See this excellent StackOverflow answer that explains Kerberos ticket and renewal lifetimes.

In the image below, the user’s password was reset on 3/30 @ 15:47:44.

After the reset, and without a new Windows sign-in session, I requested a new TGT using klist. The renewal period is 1 week. So by subtracting 1 week from the Renew Time, we calculate the original TGT was issued on 3/30 @ 15:40:10. (That’s 7 minutes before the password reset.) The start time for the new TGT is 3/30/2024 16:14:51, or over 30 minutes after the password reset.

“A Kerberos TGT and the associated session key together comprise a reusable credential for the Kerberos protocol. TGTs have a default lifespan of about 10 hours, and a default total lifetime of 7 days, if that TGT is repeatedly renewed before it expires. Attackers can steal TGTs and associated session keys and request a new session ticket at will until the renewal lifetime is reached.” ~Pg. 29

If you cannot disable a user, you should monitor where their TGT/ST requests originate from until the renewal period expires. You can use EventIDs 4768 [TGT]/4769 [ST]/4770 [renewal] for this.

What happens in Entra ID…?

Now back to Entra ID.

By default, Entra ID Connect will not sync the AD Password Reset action to Entra ID! The user’s Entra ID password will not be changed and they remain compromised until the user changes their password.

Read this rather confusing documentation quote:

Forcing a user to change their password on next logon requires a password change at the same time. Microsoft Entra Connect will not pick up the force password change flag by itself; it is supplemental to the detected password change that occurs during password hash sync. ~ Implement password hash synchronization with Microsoft Entra Connect Sync — Microsoft Entra ID | Microsoft Learn

My theory is the Entra ID Connect agent looks at the AD Password Last Set value to determine when it needs to sync a new password. An AD Password Reset changes this value twice in quick succession: once for the change done by the admin, and then immediately to 0 to indicate it needs to be changed again.

What does that mean for remediation? Imagine you:

  • Disable the user’s account and investigate the host.
  • Do an AD Password Reset to be safe.
  • Re-enable the user’s account, because their credential was changed and the investigation was inconclusive.
  • Tell the user to call the Helpdesk to get their new temp password and change it.
  • However, it’s late on Friday, and the user waits until Monday.

As soon as you re-enable their account, the attacker can login to Entra ID with the user’s old credentials! Wild stuff!

Mitigations

You can mitigate this risk in a few ways:

  1. During the AD Password Reset, do not set the “User must change password at next logon” flag. This means the PasswordLastSet value will be the date of the change (since it is essentially a password change) and it will be synced to Entra ID.
  2. Leave the user account disabled until the user is available to do a password change.
  3. If you use PWB, you likely use the ForcePasswordChangeOnLogon feature. This feature syncs the AD “Force Password Change on Next Logon” flag to Entra ID. In this case, Entra ID will update the user’s password, after the AD reset, as is expected.

If you decided to do #3, your password resets are synced to Entra ID, so problem solved!?

Wrong! What about the user’s old Entra ID tokens?

Revoke Entra ID Sessions!

Entra ID issues different kinds of authentication tokens. These tokens include:

  • Access tokens — tokens presented to a resource for access. Last 60–90 minutes (avg 75).
  • Refresh tokens — tokens presented to Entra ID to get new access tokens. Last up to 90 days.
  • Session tokens

The Microsoft ‘revoke access in an emergency’ article goes into more detail and I highly encourage you to read it.

The important thing for us is that when a password is changed in Entra ID, the value of StsRefreshTokenValidFrom (aka ‘sign in sessions valid from’ in Entra ID Portal) is set to the date of the Password Change event.

This means Entra ID refresh5 and session tokens issued before this date are invalid and the user must re-authenticate.

However, there are still two problems for us.

  1. AD Password Resets that set the “User must change password at next logon” flag change the valid from date to Jan 1, 1601, 12:53 AM which means the user’s previous tokens are still valid.
  2. Regardless of password change or reset methods, all non-password-based tokens are still valid (e.g. passwordless in Authenticator app, FIDO, etc).
  3. Session tokens remain valid.

Problem 1: AD Password Resets with the change on logon flag do not invalidate refresh tokens

Microsoft describes the impact of different response actions on refresh tokens in this article.

This chart states an ‘Admin resets password’ action revokes password-based tokens. But in my testing, this is not the case for AD Password Resets that include the ‘User must change password at next logon’ flag, which is likely the most common method!

In the GIF below, I have Access + Refresh Tokens from before the AD Password Reset with the force change flag set. After the AD Password Reset, I am still able to use my Entra ID Refresh Token to get new Access Tokens. This is because the StsRefreshTokenValidFrom is set to Jan 1, 1601 (so from forever).

Overall, this behavior is not expected, based on the Microsoft documentation.

Technically an AD Password Reset (without the change on next logon flag set) does revoke the password-based tokens. It changes the user’s password in Entra ID and sets the StsRefreshTokenValidFrom to the time of the change.

However, the default and most common method of doing an AD Password Reset (with the flag), does not work!

  1. If you do not have the Entra ID Connect ForcePasswordChangeOnLogOn feature enabled, nothing works as expected. Neither the password change or the flag are synced. The user stays compromised.
  2. If you do enable it, the password is changed and the flag is synced, but the user’s sign-in sessions are not revoked ! Any compromised tokens remain compromised until they actually login again and change their password.

That is a bad sysadmin experience and a good example of the absurd level of detail necessary to be ‘secure’.

Problem 2: Passwordless Tokens are still valid

In the refresh token chart above, Microsoft separates password-based and non-password-based tokens. I only learned about this while researching this post. For example: If a user signed in with the Authenticator app’s Passwordless feature, that token is considered non-password-based.

The important part of the chart is that Password Changes and Resets do not impact non-password-based tokens! Those tokens remain valid. This is important if a user’s device was compromised and non-password-based tokens may have been stolen.

The GIF below shows me requesting new Access Tokens after an Entra ID Password Reset.

The left terminal is a password-based token and fails.

The right is Authenticator Passwordless-based and succeeds.

Regardless of how you do AD password resets, you need to revoke all user sessions (see: Revoke-MgUserSignInSession) in Entra ID to ensure remediation.

Problem 3: Session Cookies

The final issue is session cookies. Microsoft says,

Once an application issues its own session token, access to the application is governed by the application’s session. At this point, the user is affected by only the authorization policies that the application is aware of. ~Revoke user access in an emergency in Microsoft Entra ID — Microsoft Entra ID | Microsoft Learn

It is very likely that your Entra ID-authenticated apps drop their own session cookies that control the session lifetime. So, even if you revoke Entra ID sessions, the user’s access to those apps will remain until the app session expires.

Summary

I hope this helped you understand some of the ‘gotchas’ with hybrid user remediation. I summarize the important points below.

AD

  • Attackers can still use Kerberos TGTs after a password reset/change, until the renewal period expires. Consider shortening their lifetimes. (Or disable the user or monitor where all TGT/ST requests come from.)
  • Do not limit your user investigations to AD. Entra ID logs are always needed to develop a complete picture of user activity.

Entra ID

  • You should disable users directly in Entra ID too. 30 minutes is too long to wait.
  • Even after a password change or account disable, an attacker’s access to Entra ID-authenticated resources could last an hour or longer, depending on the app configuration.
  • Always revoke compromised user’s Entra ID sign-in sessions. There are too many scenarios where existing sessions could persist (AD Password Reset, non-password-based tokens).
  • Be aware of session lifetimes/policies in your Entra ID-authenticated apps, especially for high value apps like VPNs.

Thanks

  1. It’s actually the hash of the hash or some complicated crypto shit, but the outcome is that the user uses the same password in both locations. ↩︎
  2. If you use Seamless SSO, this is more complicated, because the users may be requesting Kerberos Service Tickets (ST) for the Seamless SSO account. However, this will not record every sign-in event in Entra ID, because the same ST can be presented multiple times and you do not re-auth to Entra ID every time you access a new app. ↩︎
  3. Existing tickets are also still valid. For example, Kerberos Service Tickets presented to applications. ↩︎
  4. You should also consider the impact of NTLM caching on target devices. For example, the user’s laptop or servers they access. ↩︎
  5. Access tokens cannot be revoked. Microsoft is working on a way for applications to receive signals from Entra ID that an access token was revoked [Continuous Access Evaluation], but it’s early days. ↩︎

On This Page
  1. What is Entra ID?
  2. What is Entra ID Connect?
  3. Remediation Considerations
  4. Summary