#4180 Certificate attributes are not sanitized prior to ldap search
Closed: cloned-to-github a year ago by pbrezina. Opened a year ago by darkcipher.

I'm having an issue getting a maprule to work properly. It looks like sssd isn't sanitizing certificate attributes prior to issuing the ldap search. In this example, parentheses in the Subject DN are causing an ldap search error "Bad search filter." At the end of the example, I show the Bad search filter result from sssd and a working ldapsearch with backslash-escaped parentheses.

Additionally, altSecurityIdentities in LDAP stores a space between UID (OID...) and CN. AD is able to find and match the certificate to user when the Certificate uses a + to separate these values. I don't know if this is a standard transformation or if sssd could support a user-configurable transformation like !ad for certain character adjustments?

The smartcard is an US Government HSPD-12/PIV card.

certificate (sssctl cert-show):

Issuer: OU=Entrust Managed Services SSP CA,OU=Certification Authorities,O=Entrust,C=US
Subject: UID=1337+CN=JOHN GALT (Affiliate),OU=Department of Authentication,O=U.S. Government,C=US

SAN type: ntPrincipalName
  subject_nt_principal=1337@FEDIDCARD.GOV

LDAP:

altSecurityIdentities: X509:<I>C=US,O=Entrust,OU=Certification Authorities,OU=Entrust Managed Services SSP CA<S>C=US,O=U.S. Government,OU=Department of Authentication,OID.0.9.2342.19200300.100.1.1=1337 CN=JOHN GALT (Affiliate)

sssd.conf certmap:

[certmap/lol.gov/smartcard]
matchrule = <EKU>msScLogin<SAN:ntPrincipalName>^[0-9]+@FEDIDCARD\.GOV$
maprule = (altSecurityIdentities=X509:<I>{issuer_dn!ad}<S>{subject_dn!ad})
domains = lol.gov

sdap_attrs_add_ldap_attr:

Adding altSecurityIdentities [X509:<I>C=US,O=Entrust,OU=Certification\20Authorities,OU=Entrust\20Managed\20Services\20SSP\20CA<S>C=US,O=U.S.\20Government,OU=Department\20of\20Authentication,OID.0.9.2342.19200300.100.1.1=1337\20CN=JOHN\20GALT\20\28Affiliate\29] to attributes of [galt@lol.gov].

sss-certmap ldap search:

[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(&(altSecurityIdentities=X509:<I>C=US,O=Entrust,OU=Certification Authorities,OU=Entrust Managed Services SSP CA<S>C=US,O=U.S. Government,OU=Department of Authentication,OID.0.9.2342.19200300.100.1.1=1337+CN=JOHN GALT (Affiliate))(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))(localAuthEnabled=TRUE))] [ou=linux,dc=lol,dc=gov].
[sdap_get_generic_ext_step] (0x0080): ldap_search_ext failed: Bad search filter

ldapsearch (working):

ldapsearch -x -b ou=linux,dc=lol,dc=gov '(&(&(altSecurityIdentities=X509:<I>C=US,O=Entrust,OU=Certification Authorities,OU=Entrust Managed Services SSP CA<S>C=US,O=U.S. Government,OU=Department of Authentication,OID.0.9.2342.19200300.100.1.1=1337 CN=JOHN GALT \(Affiliate\))(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))(localAuthEnabled=TRUE))'

Hi,

thank you for the report, this issue was reported at https://bugzilla.redhat.com/show_bug.cgi?id=1780404 (might be restricted) as well. I already had a patch in my tree but forgot to create a pull-request, it is https://github.com/SSSD/sssd/pull/1036 now.

If you can tell me on which platform you are using SSSD I can try to prepare a test build with the fix.

bye,
Sumit

Metadata Update from @sbose:
- Custom field patch adjusted to on

a year ago

Metadata Update from @sbose:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1780404

a year ago

Metadata Update from @sbose:
- Issue assigned to sbose

a year ago

Hi,
...
If you can tell me on which platform you are using SSSD I can try to prepare a test build with the fix.

Hello. I'm on Ubuntu 20.04.

It looks like your pull request will handle the sanitization. Any advise on the "+" issue? Microsoft AD is able to match. Could a s/+/ / be a part of the !ad filter?

Hi,

yes, in general this is possible but I'm currently searching for some documentation which explains this behavior.

It looks your certificate has a multi-valued RDN which is allowed for PIV cards as described in https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/Common-Policy-Framework.pdf (search for 'multi-value').

According to https://tools.ietf.org/html/rfc4514 the components of a multi-valued RDN should be concatenated with the reserved character '+'.

What I'm currently missing is an explanation why AD does not use the '+' here but a space.

Btw, according to https://piv.idmanagement.gov/networkconfig/accounts/ the 'CN' part should come first followed by the 'OID' part which is different in your case. But according to https://permalink.lanl.gov/object/tr?what=info:lanl-repo/lareport/LA-UR-16-21404 section 4.1.1 both versions might be used.

bye,
Sumit

Yes, it's a multi-valued RDN (or Multi AVA) as defined in RFC4514 Section 2. Microsoft says they "support" RFC4514 Section 2 by defining MAX=1 MS-ADTS Ref. To me, this means they don't. I think they may just concatenate the multi-values with a space separator. The LDAP servers I'm using have the two values for altSecurityIdentities X509:... one with UID followed by CN, another with CN followed by UID, since LDAP doesn't guarantee order ... in LDAP's world, they are attributes, in MS-AD, they only support one, so concatenate.

altSecurityIdentities: X509:<I>C=US,O=Entrust,OU=Certification Authorities,OU=Entrust Managed Services SSP CA<S>C=US,O=U.S. Government,OU=Department of Authentication,OID.0.9.2342.19200300.100.1.1=1337 CN=JOHN GALT (Affiliate)
altSecurityIdentities: X509:<I>C=US,O=Entrust,OU=Certification Authorities,OU=Entrust Managed Services SSP CA<S>C=US,O=U.S. Government,OU=Department of Authentication,CN=JOHN GALT (Affiliate) OID.0.9.2342.19200300.100.1.1=1337

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/5135

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @pbrezina:
- Issue close_status updated to: cloned-to-github
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata