On Samba 4.24.0rc2 we noticed a mismatch in how the altSecurityIdentities value is encoded for certificate mapping (X509:<I>…<SR>…). When we set the mapping from RSAT / ADUC (right-click user -> Name Mapping…), RSAT stores the Issuer DN in this order: X509:<I>CN=Intermediate CA SAMBA,C=FR,O=SAMBA<SR>e94d23f360ebdd3a11636b78878fdf74b47df179 But Samba expects the Issuer DN with the components in the opposite order, e.g.: X509:<I>O=SAMBA,C=FR,CN=Intermediate CA SAMBA<SR>79F17DB474DF8F87786B63113ADDEB60F3234DE9 So it’s simply that the Issuer DN list is reversed between what RSAT writes and what Samba is expecting, which makes the mapping unusable when configured from Microsoft tools. Microsoft’s KB about CBA mentions altSecurityIdentities but doesn’t clarify this ordering detail: https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16 There are also community scripts/examples that build X509:<I>…<SR>… by reversing the Issuer DN components (which matches what RSAT does): https://github.com/x746b/AD-Powershell/blob/master/Get-X509IssuerSerialNumberFormat.ps1
I just tried the Samba format on a Microsoft AD 2025 and it doesn't work.
Test: 1.3.6.1.4.1.311.25.2 SID : OK (object sid in certificat) X509SKI : OK X509SHA1PublicKey : OK X509IssuerSerialNumber : Not work
Do we know how the subject name is stored by RSAT
How in the example mentioned above. RSAT currently writes the Subject DN in altSecurityIdentities in the reverse order compared to what Samba expects (Windows-style DN ordering vs Samba’s expected ordering).
Created attachment 18846 [details] testuser certificate Here is the certificate associated with the example
Created attachment 18848 [details] Proposed fix (version 1)
MR https://gitlab.com/samba-team/samba/-/merge_requests/4422
Simon are you able to try the attached patch?
It works, I'm currently testing the rest of the mappings again.
I need to double-check the other mappings; there are clearly some things that aren't clear... For example: X509:<SHA1-PUKEY> not work Samba work: X509:<SHA1-PUKEY>eef7ebcaa1e14f0720b2026b99bd9cf2aa8bb5c8 But powershell value not work: https://github.com/AzureAD/MSIdentityTools/blob/f5d0ca776c9ec00457e5a69b91a85c9a533227eb/src/Get-MsIdCBACertificateUserIdFromCertificate.ps1#L196 Name Value ---- ----- IssuerAndSubject X509:<I>CN=Intermediate CA SAMBA,C=FR,O=SAMBA<S>CN=testuser RFC822Name Subject X509:<S>CN=testuser SKI X509:<SKI>EEF7EBCAA1E14F0720B2026B99BD9CF2AA8BB5C8 PrincipalName X509:<PN>testuser@sambaad.lan SHA1PublicKey X509:<SHA1-PUKEY>B113FA8D66D7971FF3B23232BF34320EBFF15266 IssuerAndSerialNumber X509:<I>CN=Intermediate CA SAMBA,C=FR,O=SAMBA<SR>29ec7e79f356fb291b717c96be6355670ea0 I don't know what Microsoft AD accepts, so we'll have to test everything; it's going to take some time... Is Microsoft able to provide a more precise specification of what is accepted or expected?
Created attachment 18856 [details] test cert
Can you confirm that the public key value that worked was X509:<SHA1-PUKEY>eef7ebcaa1e14f0720b2026b99bd9cf2aa8bb5c8 as eef7ebcaa1e14f0720b2026b99bd9cf2aa8bb5c8 looks like the SKI value from the certificate.
Looking at the values: SHA1PublicKey X509:<SHA1-PUKEY>B113FA8D66D7971FF3B23232BF34320EBFF15266 It appears that MS is using the certificate finger print, not the key finger print. Certificate Fingerprints SHA1: B1 13 FA 8D 66 D7 97 1F F3 B2 32 32 BF 34 32 0E BF F1 52 66 MD5: 46 E4 E2 DA DD 3D BE F1 2E E2 FD EF 4A 1B C1 A8 Public Key Info Key Algorithm: RSA Key Parameters: 05 00 Key Size: 3072 Key SHA1 Fingerprint: FB 6D 0D 60 01 54 AE EC 0D 0A 84 7D 6E 9E 45 B3 F2 9A B1 DD
I'll work on a patch for this, but it won't be ready until early next week.
For the RSAT format, your patch works.
Created attachment 18857 [details] Proposed fix (version 2) Updated patch fixing <SHA1-PUKEY> matching
Simon could you check the new patch, it should fix the SHA1-PUKEY issue. Samba is now computing the certificates SHA1 fingerprint instead of the public keys SHA1 fingerprint.
Thank you, have you also implemented the SID mapping? : X509:<I>Issuer<SID>Sid https://techcommunity.microsoft.com/blog/publicsectorblog/introducing-a-new-issuersid-altsecid/4454231
https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/disable-subject-alternative-name-upn-mapping
OK for : X509:<SKI>EEF7EBCAA1E14F0720B2026B99BD9CF2AA8BB5C8 X509:<SHA1-PUKEY>B113FA8D66D7971FF3B23232BF34320EBFF15266 X509:<I>CN=Intermediate CA SAMBA,C=FR,O=SAMBA<SR>590ca00e675563be967c711b29fb56f3797eec29 X509:<I>CN=Intermediate CA SAMBA,C=FR,O=SAMBA<S>CN=testuser X509:<S>CN=testuser X509:<RFC822>testuser@sambaad.lan I also tested the compatibility/full I will try again with a Microsoft ad 2025 to see if the expected format matches.
It remains to be seen whether you want to implement "X509:<I>Issuer<SID>Sid" with UseSubjectAltName
Not in release 4.24, but maybe in a later release. I'll create new bugs to track them.
raised https://bugzilla.samba.org/show_bug.cgi?id=16009 for the new AltSecId x509:<I>Issuer<SID>sid
Raised https://bugzilla.samba.org/show_bug.cgi?id=16010 for Disable Subject Alternative Name for UPN mapping
This bug was referenced in samba master: 580051e5686d9a26d2502eb969f7a80e13519afb 3d4d7f3cb88180b205c67a6ca66373fe1fb6851e
Created attachment 18865 [details] Patch for version 4.24