> Heh heh. OK, you can paypal me at [email protected] whatever amount
> you feel is fair. I'll send you an appropriate diff to ldapdb.c.
Ok, will do. ;-)
> Cyrus provides a buffer of 1024 bytes for each username. If your DNs
> are longer than that, we'll have to truncate them (and they'll be
> useless).
> I doubt this should be a problem for you...
You're right, we don't have that long DNs at all. Not even close to that.
> Instead of doing that, we can
> just overwrite the username that canonuser passes to the auxprop.
As long as it serves the purpose. Just recall, please ...
If you rewrite some@xxxxxxxx to id000012 then you need to make sure that
Cyrus IMAPd sees id000012 as it is going to use that as the name for the
mailbox.
I need to say ... I am *not* sure about the sequence in which auxprop
and canon_user are called. But isn't it that Cyrus IMAPd will take in a
username, run it through canon_user (in case there is any), then run the
rewritten username through auxprop to retrieve a password and compare
the one that the user inputted to that.
So in pseudo-code this would be:
username = what the user entered as username
password = what the user entered as password
username = canon_user(username)
correct_password = auxprop(username)
if correct_password == password
look for mailbox username
endif
If I was right with that assumption, than you could do anyting in an
auxprop plugin to find the proper password (what you can indeed do today
already using that authz rewrite rules) but you cannot change the value
of username in the auxprop plugin. Isn't this why there are two
different hooks, i.e. canon_user and auxprop?
On the other hand, as I said in my initial posting, I think the actual
canon_user plugin would be not too complicated as it would just have to
do a single lookup, i.e. use the given username in an LDAP url to find
an object and return another attribute of that object as the
canonicalized username. E.g. search for mailAlias=someone@xxxxxxxx and
return the uid attribute of the matched object.
Regards,
Torsten
Howard Chu schrieb:
Torsten Schlabach wrote:
Howard,
> process the username, we don't change the name that SASL propagates.
> I suppose we could add a flag to the ldapdb configuration to say "use
> LDAP for the canonical name" and have it set the name in that case.
Sounds good to me. So how about going for that "easy money"?
We'll pay via PayPal!
Heh heh. OK, you can paypal me at hyc@xxxxxxxxxxxxxxx whatever amount
you feel is fair. I'll send you an appropriate diff to ldapdb.c.
I'll note that ldapdb.c is an auxprop plugin, which is called just after
canonicalization has completed. Restructuring it to act as the canonuser
plugin would be a fair amount of work. Instead of doing that, we can
just overwrite the username that canonuser passes to the auxprop. Cyrus
provides a buffer of 1024 bytes for each username. If your DNs are
longer than that, we'll have to truncate them (and they'll be useless).
I doubt this should be a problem for you...
Regards,
Torsten
Howard Chu schrieb:
Torsten Schlabach wrote:
Howard,
thank you very much for your suggestion.
I think I had tried something with authz-regexp, but are you really
sure that Cyrus IMAPd will actually see the rewritten username
afterwards? I was able to take this to the point where the
apropriate LDAP object was found and used for authentication, but
Cyrus IMAPd would have still been looking for a mailbox with the
original name rather than the rewritten one.
Hm, right. This will establish the correct DN for authentication, but
nothing further; the DN that we get is kept internally. Since it is
possible that some other mechanism (like sasldb) may still want to
process the username, we don't change the name that SASL propagates.
I suppose we could add a flag to the ldapdb configuration to say "use
LDAP for the canonical name" and have it set the name in that case.
Well ... will try, I don't remember having used
> --enable-rewrite and manually enabled SLAP_AUTH_REWRITE.
so maybe this is going to do the trick.
Regards,
Torsten
