[Date Prev][Date Next] [Chronological] [Thread] [Top]

FW: Question about restrictions on username in SASL authorization

When I first wrote up the code to extract the DN from a client certificate, in our in-house slapd code
base, I reversed the X.500 DN (put into LDAP format) so that it could be used directly as an authentication
DN. I still believe this is the most useful way to behave. The code that I committed to OpenLDAP does not
do this transformation. Kurt still has a valid point that we can get into trouble making assumptions about
externally obtained identifiers, but it strikes me that most people who will want to use this feature are
already setting up their own CAs and are already generating certificate DNs in parallel with their LDAP
DN hierarchy. Opinions, anyone?

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc 

-----Original Message-----
From: owner-openldap-software@OpenLDAP.org [mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Dave Clegg
Sent: Thursday, November 16, 2000 10:50 AM
To: openldap-software@OpenLDAP.org
Subject: Re: Question about restrictions on username in SASL authorization

I haven't seen any response. Am I on the wrong mailing list for this?
A little more digging - I think I'm correctly following the procedure for certificate based authentication using TLS and SASL EXTERNAL as described in RFC2829 $7.1.
The RFC describes this as a SHOULD - has anyone succeeded with this or is it not supported yet (2.0.6).


Dave Clegg wrote:

I'm new with LDAP and SASL, so forgive me if the question makes no sense.
What I'm trying to do is demonstrate a JNDI client using SSL client certificate authentication to bind into OpenLDAP.
The debug output from slapd where the failure occurs is:
do_sasl_bind: dn () mech EXTERNAL
conn=1 op=0 BIND dn="" method=163
==> sasl_bind: dn="" mech=EXTERNAL datalen=0
SASL Authorize [conn=1]: authcid="/C=US/O=Sybase/CN=davec" authzid="/C=US/O=Sybase/CN=davec"
SASL Authorize [conn=1]: "/C=US/O=Sybase/CN=davec" as "u:/C=US/O=Sybase/CN=davec"
slap_sasl_bind: username="u:/C=US/O=Sybase/CN=davec" realm="" ssf=0
<== slap_sasl_bind: authorization disallowed
send_ldap_result: conn=1 op=0 p=3
send_ldap_result: 48::authorization disallowed
send_ldap_response: msgid=1 tag=97 err=48
The mutual certificate exchange works OK, the normalized DN from the certificate is seeded into SASL's EXTERNAL data.
slap_sasl_bind and then slapd calls sasl_server_start successfully, retrieves the username but then applies the following test to it
(sasl.c: line 461)
} else if ( username[0] == 'u' && username[1] == ':'
         && username[2] != '\0'
         && strpbrk( &username[2], "+=,;\"\\ \t") == NULL )
We are explicitly not allowing the usename to contain some characters that are part of the DN.
The next chunk of code looks like it is going to set the authorized user's DN to
uid=<username>[ + realm=<realm>]
I have no realm here, but this DN is not what I'd want either.

I do not know how to generate a certificate where the subject name is not in X.500 Distinguished Name format, so I don't know how to keep the '=' out of username.

I must be way off base with how SSL/LDAP are supposed to be used.

I've got OpenLDAP 2.0.6, OpenSSL 0.9.5a, and CyrusSASL 1.5.24 on Solaris 2.6.
I've used the JDK1.3 keytool to create a certificate that looks like:

Alias name: davec
Creation date: Tue Nov 07 18:41:03 GMT-08:00 2000
Entry type: keyEntry
Certificate chain length: 2
Owner: CN=davec, O=Sybase, C=US
Issuer: O="Sybase, Inc.", ST=California, C=US
Serial number: 3
Valid from: Tue Nov 07 18:33:20 GMT-08:00 2000 until: Wed Nov 07 18:33:20 GMT-08:00 2001
Certificate fingerprints:
         MD5:  EB:8A:E9:C8:70:AE:D5:0A:BE:E6:89:7D:53:01:50:5B
         SHA1: 09:16:E8:21:07:61:8D:63:83:31:C4:42:82:0C:83:04:B2:36:AE:23
Owner: O="Sybase, Inc.", ST=California, C=US
Issuer: O="Sybase, Inc.", ST=California, C=US
Serial number: 0
Valid from: Tue Nov 07 12:31:16 GMT-08:00 2000 until: Thu Dec 07 12:31:16 GMT-08:00 2000
Certificate fingerprints:
         MD5:  36:19:F9:94:8D:14:8A:AE:AD:C7:53:BE:91:31:BF:44
         SHA1: CA:44:F6:3D:B8:B6:3F:A2:D5:CF:06:DA:6C:65:74:2E:15:96:25:1B


It is signed OpenSSL tools and my self-signed CA root certificate.
I've also created a Server Certificate for OpenLDAP using OpenSSL tools.
I've configured OpenLDAP to support SSL and entered this information into slapd.conf
# SSL configuration
TLSCertificateFile /usr/local/etc/openldap/servercert.pem
TLSCertificateKeyFile /usr/local/etc/openldap/serverkey.pem
TLSCACertificateFile /usr/local/etc/openldap/cacert.pem
TLSVerifyClient yes
The cacert.pem contains my CA root certificate.
I have created an inetOrgPerson to match the distinguished name in the client certificate
dn: cn=davec, o=Sybase, c=US
cn: Dave Clegg
sn: Clegg
uid: davec
mail: davec@sybase.com
userpassword: biteme
objectclass: inetOrgPerson
The java application code snippet:
if (props == null)
            props = new Hashtable();
props.put(Context.PROVIDER_URL, "ldap://localhost:636");
props.put(Context.SECURITY_PRINCIPAL, "");
props.put(Context.SECURITY_PROTOCOL, "ssl");
Context c = new InitialDirContext(props);

Attachment: smime.p7s
Description: S/MIME cryptographic signature