On Fri, Oct 25, 2019 at 06:15:05PM -0400, James Ralston wrote:
> 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.html
>
> 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 :123456...@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 123456...@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})
Hi,
unfortunately there are two different ways to encode Kerberos
principals, one is the AD way with OID 1.3.6.1.4.1.311.20.2.3 the other
is defined in RFC 4556 with 1.3.6.1.5.2.2.
To be most flexible the mapping and matching rules provide for the AD
encoding:
- <SAN:ntPrincipalName>.*@MY\.AD\.REALM
- userPrincipalName={subject_nt_principal}
for RFC 4556:
- <SAN:pkinit>.*@MY\.PKINIT\.REALM
- userPrincipalName={subject_pkinit_principal}
or if you do not know which encoding is used:
- <SAN:Principal>.*@MY\.REALM
- userPrincipalName={subject_principal}
which cover both encodings.
I'm sorry, currently there are some copy-and-paste errors in the
examples of the sss-certmap man page. I'll try to fix them in one of the
next releases.
HTH
bye,
Sumit
>
> 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…
> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
