[Date Prev][Date Next]
Re: client authentication using TLS/SASL (ITS#865)
At 09:47 PM 11/4/00 +0000, Olaf Schlüter wrote:
>Here is a partial success message. I have successfully setup an openldap
>service authenticated by TLS with client certificates. However, it has
>been a bit of a hassle and I list here the things I had to do:
>1. As already mentioned I have to use the -X option. All clients enter a
>never-ending loop if the -X credentials are not supplied. I.e. Any
>combination of -ZZ and -Y EXTERNAL without -X hangs.
I suspect the EXTERNAL mechanism has a bug or two. No authzid
should be fine (and is with other mechanisms). Does -Q work (without
>2. I have to use -O none option to get EXTERNAL into the list of
>mechanisms accepted by the client.
Yes. -O none appears to required. I believe this is a Cyrus SASL
>In a succesfull connection I get an
>ssf=0 display regardless of encryption strength in use (should be 128 or
That's an indication of the SSF provided by the SASL, which is none.
>My understanding about SASL is currently rather limited but I
>suspect that ssf=0 is the reason that the EXTERNAL mechanism gets refused
>if one omit -O none at the client. The server happily continues
>regardless of the sasl-secprops settings in slapd.conf. In my succesfull
>setup I used the default settings on the server side.
>3. I had a hard time to figure out what the correct setting of -X is. The
>certificate I use on the client side has the openssl display name of
>$ openssl x509 -subject -noout -in src/SSL/olaf4c.pem
>I learned to pass all sasl_authorize checks if I use the -X option like
>-X 'u:/C=DE/L=Baldham/O=/OU=/CN=Olaf Schlueter
>No need to hassle around with the proxy functionality then. Looks like
>the automatic derivation of the authz identity at the server side is not
The HEAD authz mapping/proxy-policy code is under development.
>4. I had to fix a line in servers/slapd/sasl.c. I am pretty sure that the
>fix is not correct but has been necessary to make things work. I include
>the diff in this message. The response parameter no longer used has been
>screwed in the bv_len part, causing ber_printf to fail upon assembling
>the response message.
Like the Cyrus SASL EXTERNAL code is not setting the response
len, leaving reslen to whatever is on the stack. You can confirm
this by initializing reslen=0 in sasl.c
>Another bug found during the course:
>ldapmodrdn defaults to authmethod LDAP_SIMPLE, making it impossible to
>activated SASL authentication. I include my diff for that bug too.