per search-dn support proposal

[Brett Lymn <blymn [at] internode.on.net>]

Hi folks,

I am starting a new thread instead of hijacking my other one.  Here is
the tail-end from the other thread.

>>
>> On another topic, can I gently prod about the change proposal I
>> posted a while ago?  I am happy to do the work but it is important to
>> me that the changes are incorportated into this project.
>
>You mean per search-DN configuration? For attribute mapping you could
>already use the "${attr1:-$attr2}" syntax for alternatives but not all
>attributes can use these kind of expressions because they are used in
>search filters. I'm guessing that could become pretty complex quite
>quickly. I would personally see if something like that could be solved
>in an LDAP proxy. I'm not against integrating such a change but since I
>have limited time available I can't guarantee that such a change can be
>integrated quickly.
>

Yes, the per search-DN configuration.  I am happy if this can be done
without hacking on code but I couldn't see how to do it.  The problem I
am trying to solve is as follows:

1) A slapd proxy that talks to two different AD realms and also to a
local ldap database.  Identities come from all 3

2) We cannot trust what the AD admins do so we use the RID part of the
SID to generate a uid for the user.  We use the uid offset feature in
nslcd to separate the uid values.  The the momment only with one AD
realm we just add 10000000 to the RID.  If we had the support we would
offset the other AD with a different number to ensure there are no uid
overlaps.

3) having menioned deriving the uid from the SID - since the AD realms
are different the SID prefix will be different.

Thoughts?

-- 
Brett Lymn
--
Sent from my NetBSD device.

"We are were wolves",
"You mean werewolves?",
"No we were wolves, now we are something else entirely",
"Oh"