New subject: smartcard mapping via msUPN SAN (OID 1.3.6.1.4.1.311.20.2.3)?

25 Oct 2019


      I was reviewing the documentation for the "certificate mapping and
matching rules for all providers" feature that landed in sssd 2.0:
https://docs.pagure.org/SSSD.sssd/design_pages/certmaps_for_LDAP_AD_file.htm...
However, I'm not sure how to use this feature to map certificates to
AD users based on the msUPN SAN.
For smartcards used with Microsoft Active Directory, the certificate
with the "Microsoft Smartcardlogin" X509v3 Extended Key Usage object
(EKU) will typically have additional X509v3 Subject Alternative Name
objects:
$ pkcs15-tool --read-certificate 01 | openssl x509 -noout -text | grep
-A 1 'X509v3 Subject Alternative Name'
Using reader with a card: SCM Microsystems Inc. SCR 3310 [CCID Interface] 00 00
            X509v3 Subject Alternative Name:
                othername:<unsupported>, othername:<unsupported>
The OpenSSL x509 tool doesn't parse the othername attributes, but we
can use asn1parse to do so:
$ pkcs15-tool --read-certificate 01 | openssl asn1parse
Using reader with a card: SCM Microsystems Inc. SCR 3310 [CCID Interface] 00 00
    0:d=0  hl=4 l=1296 cons: SEQUENCE
    4:d=1  hl=4 l=1016 cons: SEQUENCE
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]
…
  874:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative Name
  879:d=5  hl=2 l=  81 prim: OCTET STRING      [HEX DUMP]:DEADBEEFDEADBEEF…
  962:d=4  hl=2 l=  27 cons: SEQUENCE
Decoding the hex blob at offset 879 yields:
$ pkcs15-tool --read-certificate 01 | openssl asn1parse -strparse 879
Using reader with a card: SCM Microsystems Inc. SCR 3310 [CCID Interface] 00 00
    0:d=0  hl=2 l=  79 cons: SEQUENCE
    2:d=1  hl=2 l=  36 cons: cont [ 0 ]
    4:d=2  hl=2 l=  10 prim: OBJECT            :Microsoft Universal
Principal Name
   16:d=2  hl=2 l=  22 cons: cont [ 0 ]
   18:d=3  hl=2 l=  20 prim: UTF8STRING        :123456789@example.org
"Microsoft Universal Principal Name" is OID 1.3.6.1.4.1.311.20.2.3:
$ grep -A 3 msUPN /usr/include/openssl/obj_mac.h
#define SN_ms_upn               "msUPN"
#define LN_ms_upn               "Microsoft Universal Principal Name"
#define NID_ms_upn              649
#define OBJ_ms_upn              1L,3L,6L,1L,4L,1L,311L,20L,2L,3L
From http://oid-info.com/get/1.3.6.1.4.1.311.20.2.3:
{
      iso(1)
      identified-organization(3)
      dod(6)
      internet(1)
      private(4)
      enterprise(1)
      311 20 2 3
    }
The value of this object will be set as the userPrincipalName
attribute on the AD user object of the person to whom the smartcard
was issued.
And this is why Microsoft Windows smartcard login doesn't need the AD
user object to have the user's certificate preloaded into the
userCertificate attribute.
Interestingly enough, for pkinit.so's pkinit_cert_match option, the
<SAN> component-rule is also matching against the msUPN object.  You
can see this if you build pkinit.so with debugging and execute "kinit"
with "pkinit_cert_match = <SAN>.*@.*":
$ kinit
…
pkinit_cert_matching: Processing rule '<SAN>.*@.*'
parse_rule_component: found keyword '<SAN>'
parse_rule_component: found value '.*@.*'
parse_rule_component: returning 0
parse_rule_set: After parse_rule_component, remaining 0, rule ''
parse_rule_set: returning 0
crypto_retrieve_X509_sans: looking for SANs in cert = …
crypto_retrieve_X509_sans: found 2 subject alt name extension(s)
crypto_retrieve_X509_sans: unrecognized othername oid in SAN
crypto_retrieve_X509_key_usage: returning eku 0x60000000
crypto_retrieve_X509_key_usage: returning ku 0x80000000
…
check_all_certs: matching rule relation is NONE with 1 components
check_all_certs: subject: …
regexp_match: checking SAN rule '.*@.*' with value 123456789@example.org
regexp_match: the result is a match
component_match: returning match = 1
 <SAN> component-rule
Looking at the source, crypto_retrieve_X509_sans() is targeting SAN
values of GEN_OTHERNAME and GEN_DNS; all other SAN objects are
skipped.  And for GEN_OTHERNAME, it is targeting only specific OIDs
(thus the "unrecognized othername oid in SAN" line).  But one of the
OIDs targeted is msUPN.
So… how can I configure sssd to perform the same matching on the msUPN
SAN that Windows and pkinit.so perform?
From looking at sss-certmap(5), my first attempt would be something
like this:
[certmap/example.org/msupn]
matchrule = &&SAN:1.3.6.1.4.1.311.20.2.3.*
maprule = (userPrincipalName={subject_pkinit_principal})
First, I suspect I don't need to use SAN:dotted-decimal-oid form,
but I don't know which SAN:foo match is the one I actually want,
because the man page doesn't clarify which SAN:foo matches
correspond to specific OIDs.  Is it SAN:pkinit?
The same problem for the maprule: I'm not sure if
{subject_pkinit_principal} is the correct maprule to use.  "The SAN
used by pkinit" sounds correct, though.
Thanks in advance for any tips…