Re: Problems with kpasswdd handling multiple realms...

[Sean Chittenden <sean@gigave.com>]

> > Howdy.  I'm in a situation where I have multiple realms on the same
> > KDC, which is working flawlessly... except for changing passwords.
> 
> Ok, I see why you have a problem.

Thank you for turning out a patch, it is working very well for me.  I
haven't pushed this out 100% yet, but don't foresee any problems.

> If you add multiple [libdefaults]default_realm stanzas the patch
> below should do what you want.

FWIW (more for the archives than anything else), it works without
adding any default_realms because I'm using DNS for nearly all
kerberos configuration bits.

> I've not tested the patch (except compiling), I feel I need to
> digest it for a day for two more before commit it.

Works like a charm!

I'm running into a few "interesting" behaviors, however.  Assume I've
done the following four steps:

1) I login and obtain a ticket for user@ISP.COM

2) I ssh to another realm via krbtgt/EXAMPLE.COM@ISP.COM and I forward
   my ticket.

3) I'm now logged into a machine host/ssh.example.com@EXAMPLE.COM.

4) klist(1) correctly shows my principal as user@ISP.COM


Now, the things I've noticed (not necessarily all password based):

*) I don't think this is a bad thing, but, when I login as
   user@ISP.COM onto ssh.example.com, I can not change my password
   even though I pre-auth correctly and the machine I log into is
   managed by the same KDC (ie, the kdc has the keytab for this
   machine).  While I'm not inclined to think this is a bad thing, I
   don't think it's correct.

	==> kdc <==
	2005-04-18T11:32:48 AS-REQ user@ISP.COM from IPv4:a.b.c.d for kadmin/changepw@ISP.COM
	2005-04-18T11:32:48 No PA-ENC-TIMESTAMP -- user@ISP.COM
	2005-04-18T11:32:48 sending 215 bytes to IPv4:a.b.c.d
	2005-04-18T11:32:48 AS-REQ user@ISP.COM from IPv4:a.b.c.d for kadmin/changepw@ISP.COM
	2005-04-18T11:32:48 Looking for pa-data -- user@ISP.COM
	2005-04-18T11:32:48 Pre-authentication succeded -- user@ISP.COM
	2005-04-18T11:32:48 Using des3-cbc-sha1/des3-cbc-sha1
	2005-04-18T11:32:48 sending 631 bytes to IPv4:a.b.c.d

	==> kpasswdd <==
	2005-04-18T11:32:50 client used not valid principal kadmin/changepw@ISP.COM

*) "succeded" should be spelled as "succeeded."  *grin*

*) When I change my password, I'm noticing that the kdc tosses a
   message about there being no timestamp on the ticket
   request.... that doesn't seem right to me either.  Am I being hyper
   sensitive here or shouldn't the client timestamp its request to
   prevent reuse of stolen tickets?  I haven't looked into this in any
   detail, but it caught my attention and I haven't had a chance to
   dig into it yet.

	==> kdc/log/main/current <==
	2005-04-18T10:52:41 AS-REQ user@EXAMPLE.COM from IPv4:a.b.c.d for kadmin/changepw@EXAMPLE.COM
	2005-04-18T10:52:41 No PA-ENC-TIMESTAMP -- user@EXAMPLE.COM
	2005-04-18T10:52:41 sending 227 bytes to IPv4:a.b.c.d
	2005-04-18T10:52:41 AS-REQ user@EXAMPLE.COM from IPv4:a.b.c.d for kadmin/changepw@EXAMPLE.COM
	2005-04-18T10:52:41 Looking for pa-data -- user@EXAMPLE.COM
	2005-04-18T10:52:41 Pre-authentication succeded -- user@EXAMPLE.COM
	2005-04-18T10:52:41 Using des3-cbc-sha1/des3-cbc-sha1
	2005-04-18T10:52:41 sending 653 bytes to IPv4:a.b.c.d

	==> kpasswdd/log/main/current <==
	2005-04-18T10:52:44 Changing password for user@EXAMPLE.COM

*) If I add user/root@ISP.COM to .k5login on
   host/ssh.example.com@EXAMPLE.COM, I'd expect to be able to use
   user/root@ISP.COM to ksu(1) to root.  This is not the case.
   Instead, it asks for user/root@EXAMPLE.COM.  Is there any chance
   ksu(1) could look at the principal's realm instead of using the
   host's realm?  I'd ideally like to have my administrators who tend
   to client boxes to only have two - at most three - principals
   (user@, user/root@, user/admin@), instead of 3 + (1 * number of
   client realms - the root instance).

*) Lastly, imagine a box with two IP addresses:

   10.1.1.10/255.255.255.0	   - www.example.com
   10.1.1.11/255.255.255.255	   - ssh.example.com

   This particular client started off with ssh listening on
   www.example.com, but changed the firewall rules so that they can
   only log in via the aliased address .11.  This posses a problem
   only in so far as when the kerberos libraries try to authenticate a
   login request, it uses .10 as the address that it makes the request
   from, even though the client is authenticating using the principal
   from .11 (ie, the client obtains a ticket for ssh.example.com, then
   the machine relays the login request via www.example.com - which
   doesn't work).

   Is there any way to have the authentication request done by the
   libraries bind to a particular IP address?  Either in the form of a
   configuration directive, or by doing a DNS lookup and binding to
   the address of service that the user is trying to authenticate to?

Thanks in advance.  -sc

-- 
Sean Chittenden

PGP signature