[Date Prev][Date Next]
> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo Masarati
> > ie. to preserve the simplicity of the results I would
> rather have the
> > converted user not include a redundant realm specifier:
> > uid=kadmin/admin,cn=DSG.PADL.COM,cn=EXTERNAL,cn=auth
> > or
> > uid=kadmin/admin@DSG.PADL.COM,cn=EXTERNAL,cn=auth
> > -- Luke
> I see, that's the current intended behavior,
> there's nothing to do except craft your sasl-regexp
> to something like
> sasl-regexp uid=(.*)/(.+)(@[^,]+)?,cn=DSG.PADL.COM,cn=(.*),cn=auth
There's a bug in here somewhere. If the Cyrus library grabbed the name and
parsed a realm from it, then it should not have appeared redundantly when it
got to us. Either it was provided in an explicit realm parameter, or it was
left in the username, but not both. It also seems to me that they've been
deprecating the use of the explicit Realm parameter, and just appending
"@realm" to usernames. I've noticed a few emails on the cyrus lists talking
about SMTP/POP clients being unable to authenticate with their "user@domain"
email address account names, probably because of this cavalier parsing.
I note that, having created a user "hyc" with realm "fred" in my
/etc/sasldb2, this works:
./ldapsearch -Y DIGEST-MD5 -U hyc@fred
but this doesn't:
./ldapsearch -Y DIGEST-MD5 -U hyc -R fred
("fred" is not the default realm for this server...)
On the client side, the SASL library never asks for the SASL_REALM prompt, so
the -R argument is ignored. On the server, the SASL digestmd5 plugin always
parses the realm out of the provided authIDs.
If we're going to go down this road, somebody has to get Cyrus to cooperate.
Right now what we have is unusable.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support