On Mon, 29 Sep 2003, Diego Rivera wrote: > Hello all > > I ran into a brick wall today because I needed Cyrus-IMAPD to > authenticate against specific realms, but it would always use the empty > (default) one regardless of what I told it. > > So I came up with this quick patch which adds two config options: > > sasl_forced_realm: realm.com (default is null) >
The cvs version of saslauthd has ldap_default_realm. > This option causes IMAPD/POP3D/LMTPD* to use the supplied realm spec > in the sasl_server_new() calls (and thus, authenticate the provided user > against that realm). This works well with PLAIN, others may as well. > I'm well aware that this may break other auth mechanisms, but it fixed > my problem and others might find it useful. > > > sasl_email_logins: yes|no (default is no) > > This causes the realm spec to be set to "", which in turn should > allow for "email-style" logins specifying a realm. Naturally, if > sasl_forced_realm is active this option has no effect. Again - use with > care. > > More detail on the problem this solved for me: > > My problem was that I wanted multiple IMAP instances (using different > partitions, configurations, ip:port combos, etc) to authenticate against > particular realms via saslauthd (using LDAP as its backend). > > Using fastbind with saslauthd I could then authenticate the user via > LDAP binds, and find the user's dn via a filter such as > "uid=%u,ou=%r,o=LDAP". That way, I can keep separate user spaces, > separate mailboxes, but run them all on the same box. Why don't you hard code the realm here "uid=%U,ou=myrealm,o=LDAP"? You run a separate imapd/pop3d/saslauthd/slapd instance for each domain... > Please look it over and comment. > > * LMTPD: I realize that preauth could be an issue with LMTPD, so the > patch does go through the motions to NOT alter behavior if preauth is in > effect. > > Also, since I didn't know (actually, didn't check :) ) if > imapd/pop3d/lmtpd/etc automagically reload configuration changes the > configuration values are always read from the config file. If this is > not the case, then they could be cached and used indefinitely. > > Anyway - here it is. Please review it and tell me how bad it is :) > > Best > -- Igor
