[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: New guy needs some help choosing an overlay
- To: openldap-software@openldap.org
- Subject: Re: New guy needs some help choosing an overlay
- From: Jonathan Knight <j.knight@kis.keele.ac.uk>
- Date: Wed, 04 Mar 2009 15:13:44 +0000
- In-reply-to: <Pine.SOC.4.64.0901261143160.2853@toolbox.rutgers.edu>
- References: <497D86AF.8020004@kis.keele.ac.uk> <Pine.SOC.4.64.0901261143160.2853@toolbox.rutgers.edu>
- User-agent: Thunderbird 2.0.0.19 (Windows/20081209)
Aaron Richton wrote:
> I think you're making this harder than it needs to be, or at least in a
> way that I find less intuitive.
Many thanks for your help Aaron. I went down the ACL route but chose a
slightly different method.
What I did was to use the "relay" backend to duplicate the
dc=people,dc=kdir,dc=keele,dc=ac,dc=uk tree and then apply an ACL as you
suggested to block access to the relay tree if the attribute wasn't set.
i.e.
access to dn.children="dc=webct,dc=kdir,dc=keele,dc=keele,dc=ac,dc=uk"
filter="(kdirVle=no)"
by * =rcsd
access to * by * read
with the aim of blocking the auth bit (x) if the flag was set to "no".
That way the broken client could find the user, but would not be able to
authenticate. I expected that would give a better error message or
"authentication failed" rather than "user unknown".
This didn't work - I could bind as a user in that subtree with the flag
set to false with no trouble at all.
I started slapd with debug set for the ACL's to see where I'd gone wrong
and although there are a lot of calls to acl_mask, acl_get and so on
after the bind, the bind itself doesn't seem to call any acl's at all.
So I wonder if I've missed something. Should I see calls to acl's in
the bind call?
Jon.