Not a NetScaler issue, but I’m wondering if anyone else is worried of the changes in MS regarding cert authentication: https://community.citrix.com/forums/topic/253495-virtualsmartcard-authentication-using-the-certificate-san/ We’ve witnessed the issue with smartcards and in the same go we understood the issue also hits FAS virtual smartcard certs. To my understanding this will break the FAS-enabled SSO (all SAML/OIDC envs).

As @Jeff Riechers already answered on the community thread, you have to use at least FAS 2402 with SID-support

In my environment I enabled the higher security setting in the registry, and FAS worked fine. This was on 2411.

Oh, great info. Thx guys!

What are you mapping the user authentication field to? I use my FAS for my domain, and for gmail accounts with shadow accounts, and I enabled the StrongCertificateBindingEnforcement and that worked. But I am still using the SAN for placing the UPN to be authenticated with.

I'm referring to the https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-ch[…]ws-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16 article

Correct. If you want I can test out disabling the SAN and see if the SID works with that strong setting.

"The SID extension will not be used if UseSubjectAltName exists, and the value is set to 0x0." ... the customer has set this value, so will the StrongCertificateBindingEnforcement override that one?

So you would need to do both I assume. Enable StrongBinding and disable SAN. Let me test it right now in my lab and let you know what it does. 1 moment.

They have physical smartcards for the client authentication and the user accounts have the altSecurityIdentities attribute set with the X509IssuerSerialNumber, which allows the users to log in. The smartcard contains a personal unique identifier sth like 123456789@fin.gov (in the certificate SAN field) and previously this matched the users UPN. Now the UPN is changed to their email address and the cert is mapped using altSecurityIdentities

So I think there is something with the MS login portion of this. I see the SID in my FAS cert, but when I tell it to not use SAN it fails. So it's like Windows itself isn't using the SID field, I am going to see if there is something on the VDA that also needs to be enabled to support the SID entry.

The reason why they're setting the UseSubjectAltName to 0 is that they need to enable the Windows Password Hint -feature... I'll try to write this in community. I even drew a flowchart of it

this is a good discussion. we're using usesubjectaltname 0 to disable UPN based smart card mapping and instead use certificate mapping, i did not realize that the new SID extension is not used if usesubjectaltname is set to 0, this is a common configuration used within gov agencies, and changing that value to 1 is going to be a nonstarter for many, @Kari Ruissalo (WyW) have to you asked Citrix or Microsoft about this by any chance? there had been talk within US Fed government circles that there was big pushback on this strong mapping enforcement and that MS was supposedly working on an alternative but I've not heard anything recently

I have. There’s ongoing discussions and I’ve heard a rumor that the issue has been fixed somewhere already. This is pretty much a MS problem if I understand it correctly, so it’s really interesting to see if the planned enforcement schedule sticks…

@Kari Ruissalo (WyW) did you happen to see this? https://techcommunity.microsoft.com/blog/publicsectorblog/enable-strong-name-based-mapping-in-government-scenarios/4240402 I'm not sure if it would be viable for an internal CA and FAS.

Don't think I have. I try to find some time to go through this. Thanks!

Ok, I found a way to make it work, but it won't be usable. I had to manually populate the altsecurityidentities entry for my FAS user with X509:<I>DC=LAB,DC=HOME,CN=HOME-DC<SR>3B000000000030784691496852D63B00000017

@Jeff Riechers, we got it working with the instructions @Josh Bilsky shared above

Neat. What tuple did you end up using?

Similar to tuple example 1

@Kari Ruissalo (WyW) Thanks for following up and sharing with the community! It's good to know this could at least be a workaround for us although I still feel like MS should allow the SID extension to be used with UseSubjectAltName set to 0. I did share the outcome of your testing with the PKI working group at our agency for their awareness. When I saw your post initially I glossed over it due to thinking the SID extension would be the fix. I'm glad I read it closer, lol.

We Googled the topic quite a bit and the article you shared never popped up. Wouldn't hurt if MS would link that in the KB article... Good thing you did!

@Kari Ruissalo (WyW) what did you use for the OID?

I need to check the final config, I'll try to check and get back

I do have some concerns about enabling the tuple policy for certs issued by the internal CA. I feel like Microsoft's decision to force strong name mappings is to make it more difficult for an attacker to generate a cert from the internal CA that matches a weak mapping that could be used to authenticate. If you look at the language in the article, they are saying the subject name and/or subjectaltname should not contain names queried and/or built from an AD account. Isn't this effectively what FAS is doing?

I believe FAS writes (by default) the user account CN in to the Subject and in the SAN the entry is "PrincipalName: {UPN}". The strong mapping adds the requirement to fill in the altsecidenties attribute for the user objects in AD and this field by default contains the user's certificate information in the format that is described in KB5014754. The options presented in this article are tricky in "FAS point-of-view" as the certs are valid (by default) for 7 days. This would mean that every time the short-lived user certificate is renewed, the attribute should be rewritten to match the current certificate. We already started thinking of generating a script that would populate the user certs weekly for FAS and then update the attributes in AD, but fortunately the article you linked helps us to avoid this. I have pretty much always requested an additional SubCA for FAS use anyways, but to be on the secure-side with the tuple check, having a separate CA for just FAS use makes sense (you're referring to that CA's certificate thumbprint in the tuple).

@Kari Ruissalo (WyW) Now it's interesting that 2.16.840.1.101.3.2.1.3.45 id-fpki-common-pivi-authentication worked in your scenario because that OID would be stamped on the smart card certificate. I would have expected that for FAS to work with strong mapping enforced, you would have needed to use an OID that was included in the FAS certificate. I would not think 2.16.840.1.101.3.2.1.3.45 id-fpki-common-pivi-authentication would be included in the FAS certificate.

The OID in FAS cert is 1.3.6.1.4.1.311.25.2

Right, the FAS cert would have 1.3.6.1.4.1.311.25.2 which is what I was expecting the policy tuple would need to allow the login to succeed with UseSubjectAltName set to 0. I thought that because UseSubjectAltName is 0 which forces certificate mapping over UPN mapping, the SID is ignored and that's why we need the tuple configuration, but I was surprised to learn that you used an OID that is in the actual smart card certificate and not the FAS certificate. I was expecting that 1.3.6.1.4.1.311.25.2 or another OID present on the FAS certificate would be needed in the policy tuple for this to work.

The UPN suffixes are not supported for the mapping if UseSubjectAltName is set to 0x0 according to that article. So, the examples 2. and 3. don’t work. I might be lost here, it’s pretty complex for me at least.

No I think you're on the right track with policy example 1 because you're using altsecurityidentities, the thing that confused me is that it works with the OID from the smart card. Is the strong mapping already enforced on the domain controllers or is it in compatibility mode?

In my testing I could not get anything to work for authentication when I enabled the usesubjectaltname to 0. Even with the tuple including the certsrv and oid. Is there something that needed to also be added to the altsecurityidentities attribute for users as well?

@Josh Bilsky, I don't know if they have enabled the strongauthentication -knob on the DCs actually, but most certainly they have the usesubjectaltname configured, which was their initial concern

Yup, I enabled those GPO, but just could not get it to work, and was wondering if I still have to populate that altsecurityid like I had done before to get it to validate off of the SID. All I get is unknown username or password.

@Jeff Riechers you would need to have the altsecurityid populated with the name mapping along with the policy tuple to make the "weak" mapping considered "strong", once you set UseSubjectAltName to 0, it disables UPN based mapping and requires certificate mapping (aka altsecurityid)

the altsecid needs to be populated

Ok, so what type of entry would I put there? Can I just use the UPN for the user? Do I put the OID?

@Kari Ruissalo (WyW) Yeah we're still in compatibility mode here so I have not tested any of this. I'm just trying to plan for the future when this gets enforced in September. We don't have a test environment to try this on 🙃

@Josh Bilsky, fortunately one of our gov customer is creating a completely new environment and it's still in a sort of a playground mode... they're starting rollouts next week I guess and they wanted to use the strong mapping from the beginning. All in all, perfect timing... Aaaand... what's it worth, we've been discussing & planning this for two years already. Now that the actual production nears, we just needed to get this over with. Fortunately enough, it seems we got a working setup now.

Ok, I think I have this all correct, but still no luck. Throwing all my info here to see if one of you sees what I can't see.

Yeah. Not completely clear for me though what will happen for a customer if they’re running an older version of FAS like 2203. Based on the release notes that one doesn’t support the SID mapping.

@Kari Ruissalo (WyW) my thought was actually nothing would happen because the SID extension is not supported for certificate mapping, i'm trying to see if I can get more info through our MS channels, basically is the policy tuple the prescribed path forward for this scenario

Ok, still was no good. I still had the registry entry for StrongCertificateBindingEnforcement set to 2. When I switched it to 1, then it was fine.

how do you have the policy tuple configured on the dcs

Check up a few messages, I copy and pasted everything I have.

@Josh Bilsky you don’t need pw hint? 😮

@Kari Ruissalo (WyW) We only need to enter a hint if a single cert is mapped to multiple accounts, if there is only one account mapped to a cert, the SendPreauthForNewerETypes reg key on the clients eliminates the need for hints for one-to-one mappings

Great info!

@Jeff Riechers your configuration looks good to me, I would have thought that tuple and OID would work based on the documentation

you change the thumbprint in the policy tuple to something else and it works?

It continues to work when set to 1, but I change anything else and it is broken. So that seems to be the common denominator for why it doesn't work when set to 2.

your DCs are 2019+?

Yes. 2025.

my guess is that the strong setting 2 and usesubjectaltname 1 means it's successfully mapping the user against the UPN of the AD account and using the SID extension, this configuration I believe is fully supported in the newer versions of FAS

Yeah, I think that is going to be what I put in the designs going forward. Still really confused as to what in the name-based and altsecurityid isnt working. weird

well the problem is, certificate based mapping is the modern way of doing smart card auth, and in the gov space most new implementations will have usesubjectaltname=0 also in the gov space where the smart card certs are issued by 3rd party CAs, the UPN will not match the user's email address which is often required for M365 implementations, this is another advantage of using altsecid mapping over UPN mapping, like in our case our UPN is the email address but that doesn't match the UPN of the card cert so we provision the card cert in x509 format in the altsecids

Yes, all patches are up to date, unless they have specific ones not in standard windows update

i'm wondering if this has not been implemented on 2025 and if you'll have to wait until the feb 11 patch cycle

So how is this for weird. I changed my altsecurity to <I>Issuer<SR>SerialNumber and it worked. EVEN THOUGH the gpo for DC was set to Thumbprint,OID,IssuerSubject So it seems even though that setting is on the DC it fails.

My guess is the GPO won't be honored until you apply the Feb 2025 patch to the DCs.

Hmpfh... @Josh Bilsky, do you happen to have thin clients by any chance in your environments where you struggled with the strong mapping?

we do not have thin clients, but the flow you describe is similar to what we do, we map the UPN from the card certs to the employeeNumber attribute in the AD user accounts, the NS reads the UPN from the cert, matches to the AD account employeeNumber attribute via LDAP, and returns the samAccountName that gets passed to StoreFront

Oldies goldies, most of the stuff is much updated (advanced policies on NetScaler), but for the most part pretty much stuff we already did. Thanks though!

yeah i saw your post on the Citrix forum about Linux, it's hard to say how things would work going direct through StoreFront with strong mapping enforced, there could be issues there

yeah, I told the customer to give it a go though

Yeah, I was curious about how StoreFront works with regard to kb5014754 Would the SF servers require the CertificateMappingMethods key to be set?

Worth checking!

Just wanted to share the latest from Microsoft regarding this issue. I had asked them whether the policy tuple approach was the recommended path forward on this issue and this is what they responded with "Thank you for your patience as I investigated the scenario you shared with me. I would like to share my findings regarding the issues with Kerberos authentication. We have received reports indicating that Kerberos authentication using certificate mapping fails with KDC_ERR_CERTIFICATE_MISMATCH in environments where the following conditions are met: - Domain controllers are configured for Full Enforcement Mode. - The Use Subject Alternate name setting is disabled by setting UseSubjectAltName to 0. - The authenticating user has at least one mapped altSec that is using a weak altSecurityIdentity mapping. This issue may particularly affect government customers utilizing third-party SSO/FAS solutions, including Citrix Federated Authentication Service, in environments where the principal name in the subject alternate name of the certificate does not match the AD UPN. This behavior is expected within Windows. However, Microsoft and Citrix are collaborating to determine if a change can be made to better meet customer needs for FAS authentication. The correct owner of this change (Microsoft or Citrix) has not yet been determined. Consequently, we do not have an estimated time of arrival for when or if a decision will be made regarding this change, or which product (Microsoft Windows or Citrix FAS) will be affected. Thank you for your understanding. I recognize that this is not the ideal scenario at the moment, but we are actively working with Citrix to find a solution and release it as soon as possible."

Thanks for sharing @Josh Bilsky, I have ran in to similar stuff in our case. With the UseSubjectAltName = 0x0

Glad it wasn't just me.