Re: SASL EXTERNAL and client certificates

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:16 AM 5/1/2006, Adam Pordzik wrote:
>Moin,
>
>Recently, I played with client cerfificated and SASL EXTERNAL mechanism.
>There are some questions left:
>
>AUTHENTICATION/AUTRORIZATION
>
>I can authencticate with any certificate issued by a trusted CA found
>c_rehashed in /etc/ssl/certs.

Yes.

>(O'SSL compiled-in certs directory AND
>slapd's TLSCACertificatePath here) Does this implies, that anybody with
>a valid certificate e.g. issued by some public CA like Thwate or Verisign
>is authorized as "users" in ACL terms?

If those CAs are "trusted" (see first question), yes.

>Is only TLSCACertificatePath checked or OpenSSL's default directory also?

Former.

>If so, how can I prevent this (or turn-off EXTERNAL mechanism completely
>without rebuilding sasl)?

You can disable EXTERNAL using Cyrus SASL configuration file
for slapd(8).  (See Cyrus SASL documentation.)

>For now, this is no problem here at all, but
>'users' should be a delimited group, not anybody with a valid certificate.

Use of TLS+EXTERNAL is limited to valid certificates issued
by a trusted CA.  Limit your trust in CAs to limit user
certificates.

>X.509-DN/REWRITE
>
>DN/subject of the certifitace is:
>$ openssl x509 -noout -subject -in some.cer
>subject= /CN=Adam Pordzik/emailAddress=me@my.dom
>
>ldapwhoami returns:
>
>$ ldapwhoami -H "ldap://ldap/"; -ZZ -Y EXTERNAL
>SASL/EXTERNAL authentication started
>SASL username: emailAddress=me@my.dom,CN=Adam Pordzik,O=A Org
>SASL SSF: 0
>dn:email=me@my.dom,cn=adam pordzik,o=a org
>
>So, DN is in reversed RFC2253 order.

RFC 2253 defines the order for presenting RDNs in an LDAP DN
string: least-significant RDN on the left to most-significant
on the right.  OpenLDAP adheres to this RFC.

Note that OpenSSL will use other DN string representations
at times, including those with a different RDN presentation
order.

>SASL username reports 1.2.840.113549.1.9.1 as "emailAddress", slapd maps
>this AVA to "email". Why?

email is the LDAP short name for the emailAddress (1.2.840.113549.1.9.1)
attribute type.  slapd(8), being an LDAP server, uses LDAP short
names in favor of other attribute names whenever possible.

>And why can't I use "emailAddress" or
>"pkcs9email" or at least its OID as defined in core.schema for DN-
>rewriting?

Because the rewriting is string-based.

>Following works, but I suppose it wouldn't, if I change order of
>attributes names in core.schema:
>
>sasl-regexp
>   email=([^,]*),cn=([^,]*)(,.*)?
>   ldap:///ou=Users,ou=Accounts,dc=my,dc=dom??one?(&(mail=$1)(cn=$2))
>
>$ ldapwhoami -H "ldap://ldap.lan.d-dt.de/"; -ZZ -Y EXTERNAL
>SASL/EXTERNAL authentication started
>SASL username: emailAddress=me@my.dom,CN=Adam Pordzik,O=A Org
>SASL SSF: 0
>dn:cn=adam pordzik,ou=users,ou=accounts,dc=my,dc=dom
>
>So, is there also a possibility to get a sasl bind-dn in the form of
>...,cn=external,cn=auth, e.g. x509dn,cn=external,cn=auth

You should be able rewrite the subject DN to this form if you want to.

>Is it possible accessing X.509 extensions subjectAltName's attributes?

slapd(8) offers no feature to access subjectAltName values
during client certificate processing.

Kurt