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.

HTH,

Nalin

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to