Re: SASL EXTERNAL authentication blues

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

At 05:59 AM 2001-12-21, =?iso-8859-15?q?S=F8ren=20Hilmer?= wrote:
>Hi all,
>
>I have unsuccessfully tried getting slapd working with TLS client 
>authentication.
>
>What I wish to achieve (as a first proof of concept) is to have ldapsearch or 
>ldapadd, authenticate against slapd with a X.509 client certificate and then 
>act as the rootdn.
>
>I believe I have tried all the hints in the archieves on this subject 
>(obviously I cannot have done that ad it still does not work).
>
>Basically this is my understanding of how to do it:
>
>I have successfully ran the command:
>ldapsearch -x -H "ldaps://localhost" -s base -b "" supportedSASLMechanisms
>
>which lists the EXTERNAL mechanism
>
>I have then tried to run
>ldapsearch -Y EXTERNAL -H "ldaps://localhost" -s base -b "" 
>supportedSASLMechanisms
>
>But sofar without any luck.
>
>I have added -O none as suggested in a previous post as well as combinations 
>of -U and -X parameters, still no luck.

Don't specify either -U nor -X, as EXTERNAL says to use the authcid
established by the lower level security framework (TLS) and 2.0 slapd
doesn't support proxy authorization.

>I have added the root user to sasl using saslpasswd (but am unsure how this 
>should be done correctly), in that respect what bothers me most is that event 
>though i use the sasl realm dc=dk,dc=deff, slapd reports the following:

Since you are using SASL EXTERNAL, sasldb is quite irrelevant.  And
EXTERNAL has no concept of realm either.  So none of that matters.

>==> sasl_bind: dn="" mech=EXTERNAL datalen=0
>SASL Authorize [conn=0]: authcid="/DC=dk/DC=deff/CN=Manager" 
>authzid="/DC=dk/DC=deff/CN=Manager"
>SASL Authorize [conn=0]: "/DC=dk/DC=deff/CN=Manager" as 
>"u:/DC=dk/DC=deff/CN=Manager"
>slap_sasl_bind: username="u:/DC=dk/DC=deff/CN=Manager" realm="" ssf=0
><== slap_sasl_bind: authorization disallowed

This is a 2.0'ism.  2.0 does understand how to map u:/DC=dk/DC=deff/CN=Manager
to "u:/DC=dk/DC=deff/CN=Manager" to "uid=/DC\3Ddk/DC\3Ddeff/CN\3DManager" (or
better yet, to "CN=Manager,DC=deff,DC=deff".  If you like, you can hack
sasl.c to do an invalid mapping by commenting out the check for characters
to be escaped (the strpbrk() near line 469), or you can back port changes from
HEAD which provide better mapping support.


>where as you can see the realm is noted as ""

As to be expected.

>I have tried different configurations of the rootdn en slapd.conf, but I 
>believe that the correct must be:
>suffix          "dc=deff,dc=dk"
>rootdn          "uid=/DC=dk/DC=deff/CN=Manager,dc=deff,dc=dk"
>
>given the certificate DN received above.

If you comment out check above, then the subject DN associated with
"u:/DC=dk/DC=deff/CN=Manager" will be "uid=/DC=dk/DC=deff/CN=Manager".

>I am not really sure if sasl passwords added using saslpasswd are needed for 
>the EXTERNAL mechanism. I suspect not.
>
>How does sasl actually authenticate using EXTERNAL, I have tried looking at 
>the cyrus-sasl mailing list archive, but apparently it looks as it is done by 
>the server (slapd?)

EXTERNAL, itself, doesn't do any authentication.  It uses the authentication
provided by a lower-layer, e.g. TLS.


>Any help is appreciated.
>
>Kind regards
>    Søren
>
>"When in doubt, it's a classpath problem."
>
>------------------------------------------------------------------------
>Søren Hilmer, M.Sc.
>R&D manager             Phone:  +45 86 78 21 00
>IT+ A/S                 Fax:    +45 86 78 21 02
>Brendstrupgårdsvej 7    Direct: +45 87 40 08 44
>8200 Århus N            Email:  sh@itplus.dk
>Denmark                 WWW:    http://www.itplus.dk
>------------------------------------------------------------------------