On Thu, Jun 25, 2015 at 09:13:26AM +0000, Carl Pettersson (EXT BN)
wrote:
>
> One thing I just noticed is that it seems that there is actually never any
communication with the trusted domain, whose servers are in the 10.28-subnet. Ours are in
192.168.130. Does this indicate an issue with the trust, or with the machine I'm
working from?
I would say it indicates an issue with the trust.
You are taking to 192.168.130.2 (a DC from
AD.EXAMPLE.COM) to get a cross-realm TGT
krbtgt/A.FOO.COM(a)AD.EXAMPLE.COM which would allow you to get service tickets for a service
in the
A.FOO.COM realm form a DC of the
A.FOO.COM realm. But 192.168.130.2 returns
'Server not found in Kerberos database'. So it either does not know
A.FOO.COM or
there is a one-way trust going to the wrong direction.
Btw, is
A.FOO.COM a domain in the
AD.EXAMPLE.COM forest or is it form a different forest.
If it is from a different forest but not the forest root you might have to add a [capaths]
section to krb5.conf helping
libkrb5 to find what it the forest root of the trusted forest. We already have code in
SSSD to add this to the Kerberos configuration but so far it is only available for the IPA
provider since the AD provider currently does not support forest trust.
HTH
bye,
Sumit
After a bit of troubleshooting, there seems to be some problem in the RPC port negotiation
between the domain controllers. "Verify trust" works on some domain controllers,
but not all, and not the ones in the Site in which I'm testing sssd. I'll get to
fixing the network issues.
Thanks for all the help!
Carl