On Tue, 02 Feb 2016, Baird, Josh wrote:
I believe the sssd clients will need to communicate directly with your AD domain controllers, unfortunately. I wish there was a clean way around this, since we have a ton of DC's in our HUB site, and I don't really want to poke holes in the firewall(s) for all of them.
There is a way with FreeIPA 4.2+, but you need to have MIT Kerberos 1.13 on the client side. This way all clients will talk to IPA masters and IPA master would serve as Kerberos proxy using MS-KKDCP protocol.
Would someone from sssd/IPA mind chiming in here? What exactly needs to be open? What DNS record can we query to get the exact list of DC's that need to be available? Is there a way to restrict the list of domain controllers that certain sssd clients need to communicate with (for scenarios like this)?
For normal IPA-AD trust following is needed from IPA clients: - access from IPA client to AD DCs for Kerberos (port 88 TCP/UDP, 464 TCP/UDP) - access from IPA client to IPA master for LDAP (389 TCP), Kerberos (port 88 TCP/UDP, port 464 TCP/UDP) - access from IPA client to your DNS server (53 UDP), whatever that could be There might be other ports too, I don't remember off-hand. If you want to block certain domain controllers from being accessible by IPA clients, make sure you are doing it with rejection so that SSSD and Kerberos library would properly jump to the next discovered AD DC. DNS SRV records often contain all AD DCs and there is no support for sites in Kerberos library to pick up only the local ones, it takes what is given from DNS SRV records (if use of DNS-based discovery is enabled) and tries them one by one. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project