On Sun, 28 Dec 2003, Oliver Jones wrote: > Hmmm. This seemed to fail to get to the list last time (so I'm posting > again). > --------- > > I've been beating my head against this for two days now. First with 2.1 > and now with 2.2. I'm desperate for a solution. > > I'm trying to setup Cyrus 2.2 to do virtual domain logins authenticating > off LDAP. > > What is happening > ----------------- > > Cyrus IMAPd doesn't seem to be passing a full [EMAIL PROTECTED] login id > to SASLAUTHD. > > When I use cyradm to login as the cyrus user to do some config this is > what SASLAUTHD sends to my LDAP repository: > > conn=28 op=3 BIND dn="UID=CYRUS,OU=PEOPLE,DC=OU-FQDN,DC=TLD" method=128 > conn=28 op=3 RESULT tag=97 err=0 text= > conn=29 op=2 SRCH base="dc=our-fqdn,dc=tld" scope=2 filter="(uid=cyrus)" > conn=29 op=2 SEARCH RESULT tag=101 err=0 text= > > This is all good. I can login as the cyrus admin user and create > virtual domain mailboxes and Cyrus correctly creates the mailboxes. > > However when I use "imtest -m login -a '[EMAIL PROTECTED]' localhost" (or > an IMAP client) to try and login as one of our [EMAIL PROTECTED] accounts > it sends this: > > conn=26 op=3 BIND dn="UID=CYRUS,OU=PEOPLE,DC=OUR-FQDN,DC=TLD" method=128 > conn=26 op=3 RESULT tag=97 err=0 text= > conn=27 op=2 SRCH base="dc=our-fqdn,dc=tld" scope=2 filter="(uid=user)" > conn=27 op=2 SEARCH RESULT tag=101 err=0 text= > > Note that it is *not* searching for [EMAIL PROTECTED] Therefore > does not match my customers LDAP entry (see how we have setup the LDAP > dir below). > > >From the SASLAUTHD docs it suggests that the ldap_filter defaults to > "uid=%u". %u is supposed to expand to [EMAIL PROTECTED] But it is not doing > this. > > If I explicitly set SASLAUTHD's ldap_filter to "[EMAIL PROTECTED]" the lookup > succeeds however when you don't specify a domain when logging in it > searches for "uid=user@". This breaks searches for "normal" > non-virtdomain users like the "cyrus" admin user. >
Use ldap_filter: [EMAIL PROTECTED] The current version of sasl lib splits a 'fully qualified username' to userid and realm. I believe this is a wrong behavior because '@' is a valid userid character and the domain part is really not a realm identifier in such instances. Hope this helps. -- Igor
