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

Reply via email to