I'll try to answer all points in this mail:
slapo-rwm goes in the right direction, because you can condition events
based on stored knowledge of previous events; however slapo-rwm is not
the solution to your problem right out of the box, because attribute
mapping and DN rewriting are entirely decoupled, so you cannot use the
knowledge of the bindDN to alter attribute mapping. I guess you should
rather use a custom solution, inspired by slapo-rwm, that does some
pattern->action (regex?) in rewriting attributes. Or, since it is not
exactly clear how DN info should influence attribute mapping, you may
perhaps solve your riddle by having different users treated by different
virtual databases, each based on back-relay^* and with a different
mapping pattern, all pointing to the same real database.
*^I write back-relay under the assumption that the real database and the
virtual databases are in the same slapd instance; if they are not, then
use back-ldap instead.
If you want to play with DN rewriting/attribute mapping with 2.2 you
don't actually need the slapo-rwm because in 2.2 it i embedded in
back-ldap and back-meta (in 2.3 it's still embedded in back-meta but it
has been decoupled from back-ldap into an overlay to be usable with
other backends, significantly back-relay; I've figured out a way to
reuse it for back-meta as well...).
To answer Quanah's question, I think your ITS, as answered by Kurt, is
now entirely fulfilled by 2.3 code, by using back-relay and slapo-rwm;
the only thing it doesn't allow is to use the requested name instead of
the canonical one, e.g. returning "userid" instead of "uid" when
"userid" is requested (this was a long debated question; I see the issue
and I agree with the common answer that the current behavior is
preferable; for those that still wish this to be possible, the answer is
that it cannot be done with an overlay, so there's very little chance
that it will ever be possible with OpenLDAP, except by hacking the code).
p.
Digant C Kasundra wrote:
I'll have to figure out how to compile rwm with 2.2.26 and give it a try
in my test area. I haven't looked at the man page but it *seems* like
it might be what I need.
As for the RFC, yes, in a sense it can be used to potentially violate
RFC. In my particular instance, I'm trying to use it to fix an
applications misuse of RFC. I have a digital sender that wants to use
cn as the display name instead of the displayName attribute. So I want
to do a little switcharoo here.
-- DK
On Tue, 2005-07-19 at 18:06, Aaron Richton wrote:
The first question is if you can do the rewrite at all. slapo-rwm comes to
mind as a possibility here, although there may be other ways to do it (and
slapo-rwm might not be appropriate in your situation).
The second question is restricting it to only happen to certain binddn. I
imagine this would be at least somewhat dependent on the answer to the
first part. For instance, if you end up with slapo-rwm, you could probably
set some sort of binddn store/check (see "sophisticated example" in
slapo-rwm(5) man page).
If you get this working successfully, mailing back or FAQ-o-matic entry
might be in order, because I don't think this is the first time this
question has come up. I also want to insert some boilerplate here to the
effect of "this sort of stuff is a slippery slope to violating standard
schema/RFCs, be careful or at least mindful."
On Tue, 19 Jul 2005, Digant C Kasundra wrote:
Hello everyone,
Is there a way I can rename an attribute before its returned? I know
dynlist can do dynamic expansion and you can tell it to rename
attributes but how about on a per-bindDN basis? Is there a way I can
setup (perhaps where I have setup my access controls) something to say
binddn1 can see attr=displayName but call it cn when you show it to him?
-- DK
--
Digant C Kasundra
Enterprise Operations and Systems
Office of Information Technology
University of Texas at Arlington
Ph: 817-272-2208
GnuPG Public Key: http://omega.uta.edu/~digant/digant.gpg.asc
To request technical support, please contact our computing Help Desk at
817-272-2208, e-mail [EMAIL PROTECTED] or create a work order at
https://eservices.uta.edu/oitforms/workorder.html
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
