On Mon, 29 Dec 2003, Kendrick Vargas wrote:
> On Mon, 29 Dec 2003, Igor Brezac wrote:
>
> > On Mon, 29 Dec 2003, Kendrick Vargas wrote:
> >
> > > On Mon, 29 Dec 2003, Christian Schulte wrote:
> > >
> > > > Since you enabled virtdomains why do you still want unqualified logins
> > > > if not due upgrading reasons from an old installation with unqualified
> > > > logins ? This all only has to do with unqualified logins which I do not
> > > > want/need except for the global admin. If someone plans on changing the
> > > > behaviour with the global admin and defaultdomain I would really like to
> > > > keep the ability to not let a global admin in if not connecting to
> > > > localhost and of course there should be a note about the change so that
> > > > next time updating cyrus I do not open up a security hole I spent hours
> > > > to prove that its greatly closed and safe :-)
> > >
> > > Well, that's basically it. I want a global admin, so I need to have a
> > > defaultdomain set, which means the allowance of unqualified logins.
> >
> > Why is this a problem? Unqualified userid is meaningful only if there is
> > a mailbox for this userid in defaultdomain.
> >
> > > As for
> > > only being able to log in via localhost to your global admin account,
> > > it's a bug whether you like it or not :-) Relying on a bug to maintain
> > > your security is really bad security. The only time I feel secure in my
> > > setups is when I know everything is working as it should, otherwise theres
> > > always that bit of doubt about things always working right.
> >
> > This would be correct only if there is a bug. There is no bug here, but
> > rather a misconfiguration on your part. We can argue how to make the code
> > different/better in order to make it easier to configure.
> >
> > On my configuration, I can cannect as admin to any interface on the mail
> > server (I have to use fully qualified username: [EMAIL PROTECTED]), or
> > I can connect to a specific ip with an unqualified admin userid.
>
> Maybe I'm just not using cyradm correctly, I've gotta admit that cyradm
> has always been something of a black art to me. But Christian seems to be
> seeing the same problem as me, so maybe it isn't me after all. I was,
> however working for a while so my sleepyness got to me :-)
>
> Here's what I'm doing:
>
> toy:~# cyradm
> cyradm> auth cyrus
> authenticate: no connection to server
> cyradm> server toy.hudat.com
> IMAP Password:
> Login failed: user not found at
> /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/Cyrus/IMAP/Admin.pm
> line 118
> server: toy.hudat.com: cannot authenticate
> toy.hudat.com>
>
> and here's the query thats comming through...
>
> 5327 Connect [EMAIL PROTECTED] on
> 5327 Init DB hudat_sys
> 5327 Query SELECT sys_shadow.password AS
> userPassword FROM sys_users, sys_shadow WHERE sys_users.username = 'cyrus'
> AND sys_users.domain = 'hudat.com' AND
> sys_shadow.sys_users_id=sys_users.sys_users_id
> 5327 Query SELECT sys_shadow.password AS
> cmusaslsecretPLAIN FROM sys_users, sys_shadow WHERE sys_users.username =
> 'cyrus' AND sys_users.domain = 'hudat.com' AND
> sys_shadow.sys_users_id=sys_users.sys_users_id
> 5327 Quit
>
> Now, I can try and gain and the same results come right through the exact
> same way. So, lets try authing with the fully qualified user_id for the
> admin...
>
> toy.hudat.com> auth [EMAIL PROTECTED]
> IMAP Password:
> Login failed: user not found at
> /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/Cyrus/IMAP/Admin.pm
> line 118
> authenticate: authentication to server toy.hudat.com failed
> toy.hudat.com>
>
>
> 031229 14:56:56 5351 Connect [EMAIL PROTECTED] on
> 5351 Init DB hudat_sys
> 5351 Query SELECT sys_shadow.password AS
> userPassword FROM sys_users, sys_shadow WHERE sys_users.username = 'cyrus'
> AND sys_users.domain = 'imap.somename.com' AND
> sys_shadow.sys_users_id=sys_users.sys_users_id
> 5351 Query SELECT sys_shadow.password AS
> cmusaslsecretPLAIN FROM sys_users, sys_shadow WHERE sys_users.username =
> 'cyrus' AND sys_users.domain = 'imap.somename.com' AND
> sys_shadow.sys_users_id=sys_users.sys_users_id
> 5351 Quit
> 5352 Connect [EMAIL PROTECTED] on
> 5352 Init DB hudat_sys
> 5352 Quit
> 5353 Connect [EMAIL PROTECTED] on
> 5353 Init DB hudat_sys
> 5353 Query SELECT sys_shadow.password AS
> userPassword FROM sys_users, sys_shadow WHERE sys_users.username = 'cyrus'
> AND sys_users.domain = 'hudat.com' AND
> sys_shadow.sys_users_id=sys_users.sys_users_id
> 5353 Query SELECT sys_shadow.password AS
> cmusaslsecretPLAIN FROM sys_users, sys_shadow WHERE sys_users.username =
> 'cyrus' AND sys_users.domain = 'hudat.com' AND
> sys_shadow.sys_users_id=sys_users.sys_users_id
> 5353 Quit
>
> I didn't notice that it did a double query before, but, whatever... I
> tried it twice, still don't work.
>
> Now, lets look at what happens when I go in through localhost from a clean
> start:
>
> toy:~# cyradm
> cyradm> auth cyrus
> authenticate: no connection to server
> cyradm> server localhost
> IMAP Password:
> Login failed: user not found at
> /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/Cyrus/IMAP/Admin.pm
> line 118
> server: localhost: cannot authenticate
> localhost>
>
> 5357 Connect [EMAIL PROTECTED] on
> 5357 Init DB hudat_sys
> 5357 Query SELECT sys_shadow.password AS
> userPassword FROM sys_users, sys_shadow WHERE sys_users.username = 'root'
> AND sys_users.domain = 'imap.somename.com' AND
> sys_shadow.sys_users_id=sys_users.sys_users_id
> 5357 Query SELECT sys_shadow.password AS
> cmusaslsecretPLAIN FROM sys_users, sys_shadow WHERE sys_users.username =
> 'root' AND sys_users.domain = 'imap.somename.com' AND
> sys_shadow.sys_users_id=sys_users.sys_users_id
> 5357 Quit
>
> Whups, picked up root as the username, but at least it got the right
> domain! Lets try authing again:
> localhost> auth cyrus
> IMAP Password:
> localhost>
>
> 5363 Connect [EMAIL PROTECTED] on
> 5363 Init DB hudat_sys
> 5363 Query SELECT sys_shadow.password AS
> userPassword FROM sys_users, sys_shadow WHERE sys_users.username = 'cyrus'
> AND sys_users.domain = 'imap.somename.com' AND
> sys_shadow.sys_users_id=sys_users.sys_users_id
> 5363 Query SELECT sys_shadow.password AS
> cmusaslsecretPLAIN FROM sys_users, sys_shadow WHERE sys_users.username =
> 'cyrus' AND sys_users.domain = 'imap.somename.com' AND
> sys_shadow.sys_users_id=sys_users.sys_users_id
> 5363 Quit
>
>
> Look at that, it worked unqualified. It also goes in qualified too... but
> only on localhost:
>
> toy:~# cyradm
> cyradm> server localhost
> IMAP Password:
> Login failed: user not found at
> /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/Cyrus/IMAP/Admin.pm
> line 118
> server: localhost: cannot authenticate
> localhost> auth [EMAIL PROTECTED]
> IMAP Password:
> localhost>
Does 'cm [EMAIL PROTECTED]' work?
What is mysql query dump for this auth?
>
>
> Now, I'm not crazy, I've been admining boxes for 6 or 7 years now and I am
> just proficient enough that I can go in and hack away at something when it
> doesn't work, given enough time. The imap.somename.com only started
> working when I added the following to my /etc/hosts file:
>
> 127.0.0.1 localhost localhost.localdomain imap.somename.com
>
> I don't know if it worked on the localhost before I added that to the
> /etc/hosts (for resolving purposes), but I can test if you like.
This worked by accident because reverse lookup returned 'localhost'.
imapd cannot determine domainname from that thus making the defaultdomain
auth.
This will work for you:
127.0.0.1 host.imap.somename.com localhost localhost.localdomain
It'd be easier if you specify a mech rather than have cyradm chase one
that works. So try,
cyradm --user [EMAIL PROTECTED] --auth login localhost
If this works you can try other mechs.
>
> Oh, and umm... if you still don't believe me:
>
> toy:~# telnet toy.hudat.com 143
> Trying 204.235.97.76...
> Connected to toy.hudat.com.
> Escape character is '^]'.
> * OK imap.somename.com Cyrus IMAP4 v2.2.2-BETA server ready
> . login [EMAIL PROTECTED] PASSWORD
> . NO Login failed: user not found
>
> toy:~# telnet localhost 143
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> * OK imap.somename.com Cyrus IMAP4 v2.2.2-BETA server ready
> . login [EMAIL PROTECTED] PASSWORD
> . OK User logged in
> . logout
> * BYE LOGOUT received
> . OK Completed
> Connection closed by foreign host.
> toy:~#
>
This is suspicious, but it works for me:
# imtest -a [EMAIL PROTECTED] -m login localhost
S: * OK Ipass Cyrus IMAP4 v2.2.2 server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS
ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT
THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS AUTH=NTLM AUTH=DIGEST-MD5 SASL-IR
S: C01 OK Completed
Please enter your password:
C: L01 LOGIN [EMAIL PROTECTED] {6}
S: + go ahead
C: <omitted>
S: L01 OK User logged in
Authenticated.
# imtest -a [EMAIL PROTECTED] -m login x.y.z.60
S: * OK Ipass Cyrus IMAP4 v2.2.2 server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS
ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT
THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS AUTH=NTLM AUTH=DIGEST-MD5 SASL-IR
S: C01 OK Completed
OK Completed Please enter your password:
C: L01 LOGIN [EMAIL PROTECTED] {6}
S: + go ahead
C: <omitted>
S: L01 OK User logged in
Authenticated.
> >
> > Here are simple rules:
> >
> > - global admins need to be unqualified in imapd.conf
> > - Setup an interface that resolves to host.defaultdomain or setup an
> > interface that does not resolve to anything. This is required only if you
> > want to use unqualified admins when connecting to cyrus.
> > - global admins need to be unqualified in the user database
>
> Well I guess I found a bug then, because I think the proof above basically
> breaks like 3 of those rules in terms of what is actually happening. In my
> user database, the user is qualified (and, I might add, qualified to the
> right domain). The user can log into the localhost interface where
> imap.somename.com resolves to just fine, either qualified or unqualified,
> don't matter. However, when trying to go in through the public interface,
> it doesn't matter what I try, I just can't log in.
I am still not convinced that your setup is correct, although some of the
things you brought up could point to problems. I use saslauthd for auth,
but the behavior between auxprop and saslauthd should not differ. I am
also using the latest CVS code which should handle admins the same as
2.2.2-beta.
--
Igor
