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

Question about restrictions on username in SASL authorization

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
Certificate[1]:
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
Certificate[2]:
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
userCertificate;binary::
 MIIDyDCCAzGgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA5MQswCQYDVQQGEwJVUzET
 MBEGA1UECBMKQ2FsaWZvcm5pYTEVMBMGA1UEChMMU3liYXNlLCBJbmMuMB4XDTAw
 MTEwODAyMzMyMFoXDTAxMTEwODAyMzMyMFowLjELMAkGA1UEBhMCVVMxDzANBgNV
 BAoTBlN5YmFzZTEOMAwGA1UEAxMFZGF2ZWMwggG3MIIBLAYHKoZIzjgEATCCAR8C
 gYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y+r/F
 9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYV
 DwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKS
 uYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZ
 V4661FlP5nEHEIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFu
 o38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8GkotmXoB7VSVkAUw7/s9JKgOB
 hAACgYA3B1qt7/g9Jdx1J9C/cj8Bz9wr5ksqJlk01fmrjnOVWKtKQ54/iui7bCb7
 f18dl6P/WbvDGIZhvTDO4ynXRaMSNiHFg3nCL54oL3ehmhWnhUQjXRdqtwp7aVb1
 XQhiPbu8yqvFmTbnryZCzJVHGop2MDIPSUB79kkzzH2bw0vGYqOB0TCBzjAJBgNV
 HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIE8DAsBglghkgBhvhCAQ0EHxYdT3BlblNT
 TCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHHlQflSulyq/sYPSwbC
 CLvXYq/9MGEGA1UdIwRaMFiAFCDLNRgRRJWzXpnYSIwg0AKcA3/OoT2kOzA5MQsw
 CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEVMBMGA1UEChMMU3liYXNl
 LCBJbmMuggEAMA0GCSqGSIb3DQEBBAUAA4GBAJwmnBXF/das+tehiXnEMjp2RBZx
 acew+t0qGBhwDpq7KW2K+s9d05kw59vY4Lk+Na0mHGLzqQToer3d1VLX7y1pJggx
 B/oYEsXisB+l2QFh+Q99TYJK3DHKYsdRPgG5cmRW1jClgatdDzXue4gJm05ou+8P
 3W87DGN6NsG3d1ii
The java application code snippet:
if (props == null)
{
            props = new Hashtable();
}
props.put(Context.INITIAL_CONTEXT_FACTORY,
            "com.sun.jndi.ldap.LdapCtxFactory");
props.put(Context.PROVIDER_URL, "ldap://localhost:636");
props.put(Context.SECURITY_PRINCIPAL, "");
props.put(Context.SECURITY_AUTHENTICATION, "EXTERNAL");
props.put(Context.SECURITY_PROTOCOL, "ssl");
Context c = new InitialDirContext(props);
 
begin:vcard 
n:Clegg;Dave
tel;fax:626 798-3788
tel;home:626 798-1746
tel;work:510 922-3377
x-mozilla-html:TRUE
org:Sybase, Inc.
adr:;;1704 Skyview Drive;Altadena;CA;91001;USA
version:2.1
email;internet:davec@sybase.com
title:Engineering Director
x-mozilla-cpt:;29040
fn:Dave Clegg
end:vcard