[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Problem with SASL and GSSAPI
>>>>> "GOMBAS" == GOMBAS Gabor <gombasg@inf.elte.hu> writes:
GOMBAS> On Sat, Mar 17, 2001 at 04:17:36PM +0100, Turbo
GOMBAS> Fredriksson wrote:
>> I _THINK_ this is the way it's supposed to work... It depends
>> if you have the same bug in SASL as I do (I haven't found a fix
>> for that yet).
GOMBAS> You are talking about this? (It might not apply cleanly)
That applied cleanly, and seems to fix the problem...
Using '-d -1' on slapd, sending the output to /tmp/output.txt, then
doing a ldapsearch with '-U root' (after getting a ticket as root)
will give me this:
----- s n i p -----
CHROOT:/# egrep 'slap_sasl_bind: username|slap_sasl_bind: authzdn' /tmp/out
slap_sasl_bind: username="u:root" realm="[MY REALM]" ssf=56
<== slap_sasl_bind: authzdn: "uid=root + realm=[MY REALM]"
----- s n i p -----
Now, I was fiddling with the ACL's, and couldn't quite get it to
allow that principal to read secret information...
Anything that you have to be bound to the LDAP server with, is
viewed (by users read), but when trying
'by dn="uid=root\+realm=[MY REALM]" read'
on something that isn't supposed to be viewable (like userPassword),
then it don't work...
I checked the thread "ACL's for SASL compat.", and that suggested that
I do it that way...
--
Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just
^^^^^ / /(_)_ __ _ ___ __ selective about who its friends are
/ / | | '_ \| | | \ \/ / Debian Certified Linux Developer
_ /// / /__| | | | | |_| |> < Turbo Fredriksson turbo@tripnet.se
\\\/ \____/_|_| |_|\__,_/_/\_\ Stockholm/Sweden