This is much better. I'd probably put the mechanisms outside of the libsasl box, since they are (almost always) loaded dynamicly.
OK.
NTLM can use either Windows NT networking or the auxprop plugins.
I don't quite get you there. I'll have a deeper look into the NTLM support and see if I get a better understanding of it.
GSSAPI/KERBEROS_V4 rely on the Kerberos Domain Controllers (KDC).
Yeah. I left that off because it seemed pretty obvious, but p'haps it's best included.
You should probably add these links to the wiki. Directly attaching the files would be even better.
Sure. I'll do that, I just wanted to make sure it was going to be complete and accurate first.
Later I'd like to collect and document some common working configurations for the wiki, if folks are OK with that. I suspect that
There is already a section for this, so it is definately encouraged:
http://asg.web.cmu.edu/twiki/bin/view/Cyrus/SampleCyrusConfigurations
Sure. I'll collect things up and write it up in a bit.
I'd discourage people from using pam if they can at all avoid it. Certainly going saslauthd->pam->ldap is pretty questionable given that saslauthd has an internal LDAP module.
I personally like using PAM because it lets me centralise my authentication setup to one place, yet it's flexible enough to handle different needs for different apps. I like being able to use multiple sources of user information (it's handy when transitioning things). As it happens, I don't currently use anything but LDAP, but the flexibility is nice. As my Cyrus host doesn't have a high mail load, and has a lot of other roles as well, it's been useful to be able to just link Cyrus into the main LDAP config.
To be honest, I used pam->ldap simply because I already had libpam_ldap working happily and it was easy to integrate Cyrus into it. If I spot some good documentation on the use of saslauthd's LDAP support I'll try it out. I'd be interested in your reasons for avoiding PAM though.
Craig Ringer
