AD FS OIDC ID_TOKEN sub changed after patching

Question

I have AD FS running on a Server 2019 machine that was patched over the weekend (KB5083769 and KB5082417).

A user that was previously reporting a specific sub in the id_token that would come from AD FS for an OAuth2 / OIDC based login was unable to log in after patching, and after investigation it was determined that the sub was different.

Per the documentation, I believe this is expected only if the client ID or the uniquely identifying properties of the underlying AD user are changed. No properties were changed in AD and the client ID has remained consistent.

Are there any known issues regarding AD FS sub generation for users that could cause this behavior?

Answer 1

@Jay Myers
ADFS uses the Anchorclaim and the ClientID + a farm specific entropy value to generate the SHA256Digest value
for the SUB claim of an ID token.

It can happen though that the anchorclaim changes due to
a change of the AnchorClaimtype configuration on the claims provider trust itself
or
in some instances (often the change would occur sporadic from one logon to another) due to case sensitivity of the AnchorClaim value itself.

the later in particular occurs if the builtin AD Claims provider is used in that case the Windows LsaLookupCaches can become "polluted" by a user provided input. In particular if the anchorclaim is also used for the logon.
The LsaLookupCache entry my then be created with the value provided by the user
and when the Anchorclaim is populated Windows will not necessarily query from DS but fetches the value now from local Cache.

You may need to disable the cache by setting the following registry key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
Name : LsaLookupCacheMaxSize
Type: Dword
Value: 0

additional informations about that caching behavior can be found in
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/lsa-lookup-performance-counters#lsa-name-cache

Answer 2

Hi Jay,

A change in the OIDC sub value should be investigated carefully, because AD FS exposes sub as a pairwise subject identifier. Microsoft’s AD FS documentation shows that the OIDC discovery document advertises subject_types_supported as pairwise and includes sub as a supported ID-token claim.

Microsoft Learn

Since you have confirmed that the client ID and the relevant AD user attributes have not changed, I would not assume that the patch itself is intentionally regenerating the sub value. I would first compare the complete OIDC request and token before and after patching.

In particular, I would check:

Client/application configuration – confirm that the same AD FS application/client ID and relying-party configuration are being used.

OIDC request parameters – compare the client_id, issuer, redirect URI and other relevant parameters from the working and failing requests.

AD FS configuration/claim rules – verify that no claim-rule or application configuration changed during the patching/maintenance window.

User identity attributes – compare the underlying AD object and the identifier used by the AD FS configuration, rather than only checking UPN/display name.

AD FS logs/tracing – capture a token from the same user and same client before/after the change, then correlate the request with the AD FS event logs.

I would also recommend checking the discovery document from the same AD FS endpoint to confirm that the application is still using the expected OIDC configuration. Microsoft documents that AD FS generates the ID token after authentication and claim processing.

Microsoft Learn

If the same user, same client ID, same AD FS configuration and same relevant identity attributes are confirmed, but the sub value changed immediately after the Windows updates, that would be a good case to investigate specifically as a possible AD FS regression. At that point, the exact AD FS version/build, installed KBs, token samples (with sensitive values redacted), and relevant AD FS event logs would be useful for Microsoft Support to investigate.

I would avoid using a mutable value such as UPN or email as the application's permanent user key. Microsoft recommends using an immutable identifier for reliably identifying users.