[Freeipa-users] Cross realm authentication

[Dan Scott]

Hi,

On Fri, Dec 18, 2009 at 13:40, Nalin Dahyabhai <nalin at redhat.com> wrote:
> On Fri, Dec 18, 2009 at 12:31:44PM -0500, Dan Scott wrote:
>> I have added these principals to both FreeIPA servers:
>>
>> krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM
>>
>> (I see the warning in the FreeIPA documentation about avoiding the use
>> of kadmin and kadmin.local - I can remove these principals if
>> necessary).
>>
>> There are master and replicated FreeIPA servers in both realms and
>> they have the required ports open at the firewalls (both directions)
>>
>> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Preparing_for_an_IPA_Installation-Required_Ports.html
>>
>> So clients in A.EXAMPLE.COM should be able to authenticate to
>> C.B.EXAMPLE.COM, but not the other way around (This is how I would
>> like it setup).
>>
>> However, this does not appear to work. I assume that I need to add
>> some entries to the LDAP server as well? Does anyone know if this is
>> true and if so, how I should go about it?
>
> If you added entries using kadmin, and kadmin can read them back, then
> the KDC should be able to read them, which means you should be fine.
> Just don't expect to be able to do much more with those entries. :)
>
> To troubleshoot this, we can walk through the steps that the client
> software usually does behind the scenes.  First, make sure you can get
> the first cross-realm credential from the local KDC, after getting creds
> for a client of the A.EXAMPLE.COM realm:
>  kinit admin at A.EXAMPLE.COM
>  kvno krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM
>
> (The 'kvno' tool tells you the version number associated with the key,
> but in order to do that, it has to fetch credentials from the KDC, which
> is all we're really after here.)  If you can get a cross-realm ticket,
> then you know that the first realm's KDC is set up correctly.  Assuming
> the two realms have the same keys for the cross-realm service, you
> should then be able to use that ticket to get tickets for a service in
> the foreign realm, from the foreign realm's KDC:
>  kvno host/foreign_kdc_hostname at C.B.EXAMPLE.COM
>
> Here, I'm assuming you can fill in the name of a service principal in
> the second realm if you don't have a "host" entry for the foreign
> realm's KDC.  If this succeeds, then cross-realm authentication is
> correctly set up as far as the KDCs are concerned.
>
> If the first step fails, check that your clients "know" that the
> cross-realm credentials can be obtained directly from the local realm's
> KDC, and that there aren't any intermediate realms that it needs to go
> through.  If they don't, you're probably seeing failed requests for
> credentials for "krbtgt/EXAMPLE.COM" in A.EXAMPLE.COM's KDC log
> (/var/log/krb5kdc.log).
>
> To fix that, you'll need to add some configuration to the client system
> /etc/krb5.conf files.  The configuration snippet for the client system's
> krb5.conf will probably look like this:
>
>  [capaths]
>    A.EXAMPLE.COM = {
>      C.B.EXAMPLE.COM = .
>    }
>
> If the second step fails, then my first guess would be that the keys
> that the two realms have for the cross-realm principal are somehow
> different.  In that case, resetting both by changing their passwords (it
> can be a randomly-generated password, but it should be the same in both
> realms) should be the simplest fix.

Thanks for that information - it clarified a few things for me.

Here's my output:

$ kinit
Password for guser2 at EXAMPLE.COM:
$ kvno krbtgt/A.EXAMPLE.COM at A.EXAMPLE.COM
krbtgt/A.EXAMPLE.COM at A.EXAMPLE.COM: kvno = 1
$ kvno krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM
krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM: kvno = 1
$ kvno host/server.c.b.example.com at C.B.EXAMPLE.COM
host/server.c.b.example.com at C.B.EXAMPLE.COM: kvno = 3
$ klist
Ticket cache: FILE:/tmp/krb5cc_1147_tvDVq8
Default principal: guser2 at A.EXAMPLE.COM

Valid starting     Expires            Service principal
12/18/09 14:48:28  12/19/09 14:48:23  krbtgt/A.EXAMPLE.COM at EXAMPLE.COM
12/18/09 14:48:33  12/19/09 14:48:23  krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM
12/18/09 14:48:35  12/19/09 14:48:23  host/server.a.example.com at C.B.EXAMPLE.COM

So all appears to be working correctly, right? This worked the same,
with and without the [capaths] entry which is a little strange. Having
said that, my DNS configuration and the KDCs for both realms are
accessible from my client - I can do:

kinit user_in_a_example at A.EXAMPLE.COM

and

kinit user_in_c_b_example at C.B.EXAMPLE.COM

and both will obtain a valid ticket.

I've just read Simo Sorce's comments about system users and I think
that this may be causing some of my problems. If I read this
correctly, I cannot just ssh from one machine to another in a
different realm using a user in the first realm? Is this related to
the LDAP configuration/entries?

I would like to use this with http authentication. i.e. I would like
to permit users in A.EXAMPLE.COM to authenticate (and authorize, if
possible) with a website which is controlled by C.B.EXAMPLE.COM.

When cross-realm authentication is discussed, does that mean only
authentication? Or does it include authorization as well?

Thanks for all your help,

Dan