On to, 12 marras 2020, Natxo Asenjo via FreeIPA-users wrote:
We have a working cross realm trust between AD (2016, domain.local) -> Idm
(rhel 7.9, idm.domain.local).
So we can log in using our AD credentials to the rhel servers, and get
kerberos tickets and the rbac rules are enforced coupled to AD groups
mapped to Idm external groups.
If i run klist.exe on a cmd prompt, I see several DOMAIN.LOCAL tickets on
the Windows client.
One thing I cannot seem to get working is to use putty with gssapi
delegation (user name(a)domain.local and selecting the gssapi credentials
delegation) on a windows client joined to AD. So using name/password it
works, but single sign on does not.
The only thing I can think of is a firewall, but I cannot find any
documentation about firewall requirements between a windows client and a
idm host. The only port open that I know of is 22/tcp for sshd, so the
windows host can get to putty. This is a pretty locked down setup, I have
no access to the firewall logs or administrator rights on the windows
client to run a packet capture.
Do you need kerberos access from the windows clients to the Idm servers for
Yes. Pretty much like for Windows systems accessing any of the domain
controllers for the domains where Windows servers they want to login
into are located.
There is no magic, of course. Windows client is a Kerberos client, it
asks own domain controller to get a service ticket to the target
server's principal. AD DC issues a referral to IPA realm, so client
(Windows client) must chase that referral to IPA KDC and ask the same
question there, now with a cross-realm TGT it obtained from its own DC.
This behavior of Kerberos application stays the same whether actual KDC
implementation is Active Directory or FreeIPA.
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland