Re: Problems with kpasswdd handling multiple realms...

[Love Hörnquist Åstrand <lha@kth.se>]

Sean Chittenden <sean@gigave.com> writes:

>> > 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.

The patch ended up looking like this:

http://people.su.se/~lha/patches/heimdal/kpasswd-multi-realm

> 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

Try adding

[libdefaults]
        default_realm = ISP.COM

on the machine that run the kpasswdd.


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

Fixed, thanks.

> *) 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.

The No PA-ENC-TIMESTAMP warning is normal and ok.

> *) 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).

If you do the multi realm trick, it might help you, but that will also
require all you users to have unique usernames over all machines.

> *) 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?

Today, no, except using address-less tickets. I've been thinking about
making the kerberos library smarter in how it picks the local address when
doing requests, but that doesn't really solve problems for applications.

Love

PGP signature