[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
ldapdb.c usage: what objectClasses for a proxy entry?
[Note: sent again because it didn't show up on the list on first try at
16:14:56 -0400. Apologies for any multiple copies]
Hi List-
I just discovered ldapdb.c in the OpenLDAP package and am trying to get
it all set up properly. I think I got it compiled, linked, and
installed ok (AFAICT). Thanks very much for writing this, Howard. I
had just given up on getting DIGEST-MD5 authentication going for IMAP
clients authenticating to a Cyrus IMAPd server with shared secrets
stored in an LDAP directory when I just stumbled across ldapdb.c!
Wonderful!
I've also just finished reading an extremely enlightening thread on the
subject started by Tony Earnshaw in the archives at:
http://www.openldap.org/lists/openldap-software/200310/msg00192.html
Contributors to the thread were Igor, Quanah, and Howard.
I've also read all the recent threads in the archives on using ldapdb as
a sasl auxprop plugin. I also read about proxy authorization in 10.3 of
the Admin Guide.
There are many new concepts here for me, so I've tried diligently to
understand them as well as can be before asking here, but one thing
remains unaddressed in the threads I've read thus far: just what kind of
an entry in the DIT should a "proxy" be?
I realize that the saslAuthzTo and saslAuthzFrom attributes can be added
to any entry (or that seems to be the case based on what I read in the
Admin Guide), but if I want to have Cyrus IMAPd make a call to the Cyrus
SASL Library in a "role" of "SASL" (or something) with ldapdb_id:root
and ldapdb_pw:secret credentials as written in
/usr/lib/sasl2/Cyrus.conf, then "SASL" is acting as a proxy for the user
who's trying to authenticate and I'm thinking that I should probably
have some special entry in the DIT for this "proxy user" or "proxy
account."
I'm sure there are many ways to do this, but this one just seems to make
the most sense to me, and I don't want to hose up my entire directory as
Tony mentioned doing in his thread, so a specialized entry seems
appropriate. I'm guessing that I may also have other entities acting as
proxies someday, so perhaps a branch (daemons?) in the DIT to contain
these proxies is best. This is what I'm thinking, and with those
thoughts as a starting point, just what sort of objectClasses should
make up one of these proxy entries (here's getting into the "art" of
this subject, I guess)? inetOrgPerson doesn't seem right since this is
not a real person. Perhaps applicationEntity would be one? Is this the
sort of thing that objectClass was meant for? Perhaps also
posixAccount? And/or maybe organizationalRole? Any suggestions? What
have others done here?
TIA.
--
Kevin
http://www.gnosys.us