[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SASL authentication with open ldap
Tony Earnshaw wrote:
> JOYDEEP wrote, on 13. mar 2007 09:13:
>
> [...]
>
>> 1> I have executed "saslpasswd2 admin" to create the user admin in the
>> sasldb2
>>
>> 2> "sasldblistusers2" shows as below
>>
>> admin@linux.kolkatainfoservices.in: userPassword
>>
>> 3> now the command *ldapsearch -H ldaps://* when asks the password I
>> gave the admin password stored in sasldb2.
>> and now it is working.
>
> [...]
>
>> 5> BUT when I added entry for Manager ( as per root dn) and provide the
>> password of manager it is not working.
>> even it is not working for any other uesrs which I have added in
>> sasldb2.
>>
>>
>> How can I fix the problem ?
>>
>> PS: here is my ldif as attachment
>
> I don't see any entry for admin in the ldif. 4 things are important:
>
> 1: There has to be a section for SASL mapping rules in
> slapd.conf/cn=config hierarchy as detailed in the admin guide 11.2.6.
> Something like:
>
> sasl-regexp uid=(.*),cn=digest-md5,cn=auth
> "ldap:///dc=example,dc=com??sub?uid=$1"
> What does yours look like?
Thanks a lot Tony. Now it has become clear to me that slapd.conf has
some mechanism to talk with sasl. I don't have the
sasl-regexp uid=(.*),cn=digest-md5,cn=auth and it is the problem.
Thanks for pointing out my mistake. But still I can't understand that
how it works with admin in sasldb2 when there is no entry in
ldif file and the configuration u suggest is not present in my slapd.conf
>
> 2: If you want to proxy authorizations using admin (for example), you
> have to have an admin user in your directory tree (can be anywhere)
> and you have to give him proxy authorization (saslAuthzTo) as stated
> in the admin guide 11.3.3 - this will show up in an ldif of his record
> something like:
>
> dn: cn=admin,dc=example,dc=com
> changetype: modify
> add: saslAuthzTo
> saslAuthzTo: dn.regex:cn=.*,dc=example,dc=com
>
> 3; Your ACLs should give the proxy user enough rights to read user
> passwords and whatever attributes necessary.
>
> 4: Using the logs are ok, but the way to test your configuration out
> is with ldapwhoami (man 1 ldapwhoami). If your setup doesn't work with
> ldapwhoami it's not right.
>
> Best,
>
> --Tonni
>