Hi,
On Fri, Dec 18, 2009 at 13:40, Nalin Dahyabhai na...@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@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 ad...@a.example.com
kvno krbtgt/c.b.example@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_hostn...@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 gus...@example.com:
$ kvno krbtgt/a.example@a.example.com
krbtgt/a.example@a.example.com: kvno = 1
$ kvno krbtgt/c.b.example@a.example.com
krbtgt/c.b.example@a.example.com: kvno = 1
$ kvno host/server.c.b.example@c.b.example.com
host/server.c.b.example@c.b.example.com: kvno = 3
$ klist
Ticket cache: FILE:/tmp/krb5cc_1147_tvDVq8
Default principal: gus...@a.example.com
Valid starting ExpiresService principal
12/18/09 14:48:28 12/19/09 14:48:23 krbtgt/a.example@example.com
12/18/09 14:48:33 12/19/09 14:48:23 krbtgt/c.b.example@a.example.com
12/18/09 14:48:35 12/19/09 14:48:23 host/server.a.example@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_exam...@a.example.com
and
kinit user_in_c_b_exam...@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
