After a fair amount of struggling and reading, I've manged to get the
libldapdb SASL auxprop plugin working, so I can offer DIGEST-MD5
password exchange services to SASL aware applications (for example:
Cyrus IMAP server). I'm VERY excited!

But I've been staring at this for so long, I don't trust my judgment on
a security question, so I thought I'd ask the experts.

I'm storing only regular user accounts in the LDAP server, with standard
system accounts being stored in the /etc/password /etc/shadow files of
my RedHat Enterprise Linux 3.0 box.

When CyrusIMAP initiates an SASL query to OpenLDAP, it comes across as:
authcid="uidNumber=100+gidnumber=12,cn=peercred,cn=external,cn=auth".
I've set up the sasl configuration file to use ldapi:/// with mechanism
EXTERNAL. There is no user with these numbers in my directory. 100 is
the cyrus user and 12 is the mail group.

Now for Cyrus to authenticate a user, it seems that it must be able to
act as a proxy on behalf of someone else (such as the mail user trying
to log in).

Right now, I just used a regex to map the authcid above immediately to
the directory admin. That user appears to have implicit rights to
authenticate as someone(anyone) else, without me needing to turn on
"sasl-authz-policy to", and things work swimmingly. My question is, am
I opening up a huge security hole here? Or is there a more advisable
way to be doing this? I have this nagging feeling this may not be a
secure way to do this.

The question is, are there any other processes that the sasl uid can be
running, that will issue requests over ldapi? And are those processes
the sort of thing that really should not have admin privilege in the
LDAP directory? If the answer is "no" then you're fine.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sunhttp://www.symas.comhttp://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support