MS Certificate authentication changes

This article will be updated if new information is found or something is incorrect.

Backgrounds

Overview

The actual change is described in MS KB5014754. In a nutshell the change enforces strong mapping of certificates to an on-premises AD user object. This change will impact many (government) users that are using smart cards.

For many cases the user mapping is handled by reading the Subject Alternate Name information from the smart card and mapping this information with the AD user object. The SAN field in the certificate usually contains a unique User Principal Name -formatted user ID, which is often mapped to the on-prem AD userPrincipalName attribute. This will be considered as a weak mapping after the change and will stop working.

Affected use-cases

Schedule

Microsoft has published a KB-article (KB5014754) originally in the beginning of 2023, but the dates have been updated since a couple of times and now the changes described in the article will go live this February (2025). There is a way to use the compatibility mode until September 2025, but after that the change is enforced to all environments.

Detailed

In the MS KB5014754 three mappings are cosidered strong. The most common one I’ve seen is the X509RFC822 (Certificate SAN mapped to AD user object UPN):

Mapping	Example	Type	Remarks
X509IssuerSubject	“X509:<I>IssuerName<S>SubjectName”	Weak
X509SubjectOnly	“X509:<S>SubjectName”	Weak
X509RFC822	“X509:<RFC822>user@contoso.com”	Weak	Email Address
X509IssuerSerialNumber	“X509:<I>IssuerName<SR>1234567890”	Strong	Recommended
X509SKI	“X509:<SKI>123456789abcdef”	Strong
X509SHA1PublicKey	“X509:123456789abcdef”	Strong

With physical smart cards, I’ve seen also the UseSubjectAltName registry value being set to 0, which effectively disables using the SID extension, as stated in KB5014754 under the “Registry key infromation” section.

The SID Extension detection and validation used by the Strong Certificate Binding Enforcement has a dependency on the KDC registry key UseSubjectAltName value. The SID extension will be used if the registry value does not exist or if the value is set to a value of 0x1. The SID extension will not be used if UseSubjectAltName exists, and the value is set to 0x0.

This breaks Citrix FAS SSO.

What to do?

Need more time?

Physical smart cards

Windows workstations

I’ve seen customers enabling the Password Hint feature on Windows endpoints. This means that for the users to be able to login using the smart cards, they will need to enter both their username (in sAMAccountName or userPrincipalName format) together with the smart card PIN. To be able to do so, they need to set the UseSubjectAltName registry value to 0 as described in the Microsoft Article. (In one case the customer used to have their smart card SAN UPN as their AD/LDAP UPN in form abc12345678@smartcard.issuer, but now they needed to update the AD UPN to don.doctor@agency.gov due to SaaS apps SSO requirements).

Apparently there is also a registry value SendPreauthForNewerETypes (a DWORD under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters) that should be set on the clients together with the UseSubjectAltName key that should allow bypassing the password hint dialog. However, this requires that a certificate is explicitly bound to only one user account. I have not seen this tested anywhere.

Thinclients

The authentication from the thinclients is configured to StoreFront directly (and the SF should have the Smart card authentication option enabled). As of now; I’m not sure if this is supported when the strong mapping is enabled and there are also Windows endpoints with Password Hint enabled.

Update 2025-04-01!

In some use-cases the thinclient (Linux) authentication works with StoreFront if you:

• Set the UseSubjectAltName in the StoreFront server registry to 0
• Use browser as the client rather than the full Workspace App for Linux
• On the StoreFront Server Disable TLSv1.3 and HTTP/2
  • CTX559984 for instructions
  • IIS Blog for more information

Virtual smart cards

Environments without physical smart cards

Citrix Federated Authentication Service 2311 introduced a new feature:

Federated Authentication Service certificate request enhanced to include SID. The certificate request from FAS to the certificate authority is enhanced to include the SID parameter. For users who enable the Supply in the request option of the Subject Name properties in the Citrix_SmartcardLogon template, this addition allows FAS to operate with the certificate authentication changes detailed in KB5014754. These authentication changes are already supported for users who use the default setting Build from this Active Directory information

The SID mapping is achived by adding a new extension with Object Identifier (OID) 1.3.6.1.4.1.311.25.2 to each issued certificate. This

So, if you’re running LTSR versions, make sure you upgrade the FAS to LTSR 2402 or on CR path to 2311 or later.

Environments with physical smart cards

This one was a bit harder to find (shout out to World of EUC Slack / JoshB!).

If you have all of these:

• Strong Mapping enforced (StrongCertificateBindingEnforcement set to 1 or 2)
• UseSubjectAltName set to 0x0

The FAS virtual smart card SSO won’t work, unless you follow the instructions in the MS article Enable strong name-based mapping in government scenarios. This article describes how to overcome the scenario descibed above and still have Citrix FAS SSO working.

To get this working properly, you need:

• Enable the GPO “Allow name-based strong mappings for certificates” on Domain controllers
• Configure the GPO with the necessary tuples (Strong Name Match Rules)
• For each user add the tuple according to the example 1 (can be autogenerated)

Example

• In Domain Controllers GPO, enable the policy “Allow name-based strong mappings for certificates” under Computer Configuration / Administrative Template / System / KDC.
• Set the “Strong Name Match Rules” value to {issuingCAthumbprint}; 2.16.840.1.101.3.2.1.3.45;IssuerSubject
• For each user objects AltSecID attribute, set the value to X509:<I>{issuingCA-CN}<S>{userCN}

In the example the {issuingCAthumbprint} should match the thumbprint of the Issuing CA you’re using to issue the FAS User certificates. If you have many Issuing CAs, you can add them in to this multi-valued field. This list should also contain the list of Issuing CAs for your physical smart cards.

The {issuingCA-CN} should contain the common name for your CA.

• For Domain CA could be sth like C=FI,O=My Organization,CN=Org Issuing CA
• For physical smart card CA it might be sth like C=FI,O=Digi- ja vaestotietovirasto CA,OU=Sosiaali- ja terveydenhuollon ammattivarmenteet,CN=DVV Social Welfare and Healthcare Prof. Certificates - G2R (example of one of the Finnish healthcare Issuing CAs subject)

The {userCN} should contain

• For Domain CA the user Common name in the FAS Issued Certificate (depending on the FAS Citrix_SmartcardLogon template subject setting), but likely something like CN=Domain\sAMAccountName or CN=user.principal@domain.loc.

Followup

There’s a lot to digest in this article and it might contain some mistakes. Please let me know if there’s something I have understood wrong or if there’s some information missing.

You can reach me best via email at kari.ruissalo@comping.fi.