On Thu, Apr 06, 2017 at 02:39:02PM -0400, Chris Dagdigian wrote:
> I see similar things in our environment where IPA is used as "glue" between
> AD Forests that have a 1-way trust relationship. We believe that the root
> cause has something to do with the 30+ domain controllers the IPA client
> tries to make contact with (in seemingly random order) across the AD Forest.

When an AD user logs to an IPA client, there are actually two actions --
a user lookup and the authentication.

The user lookup is in fact done by the SSSD instance running on one of
the IPA masters, the clients just talks to the masters, but the SSSD on
the master talks to one AD DCs.

Authentication is done directly against one of AD DCs.

> Very hard to reproduce but the "subdomain marked offline" problem is one we
> see often in the sssd logs. We think that there are some AD servers in our
> sprawling environment that we either can't reach properly over the network
> (firewalls, etc.) or are just plain not configured to talk properly to us.
> Login success depends on hitting a happy domain controller.
> We are VERY interested in the recent updates to IPA server that seem to
> indicate we can 'pin" clients to certain specific AD controllers and from my
> understanding we just need to wait until the SSSD software gets broad
> support for this feature as well. Once we can do that we plan to pin our
> clients to named controllers and see if that helps with any of the
> intermittent login problems.

I don't think there are any changes needed to the the IPA server (maybe
some management framework), but in general you're looking for this

(after we migrated the upstream projects from fedorahosted to pagure,
our documentation is still in a bit of a flux, but we're migrating the
docs gradually..)

As the design page says, you will be able to set up the AD DCs the IPA
masters talk to using the subdomain configuration, but the DCs the
clients authenticate to must currently be set in krb5.conf on the
clients until https://pagure.io/SSSD/sssd/issue/3336 is implemented.

> One workaround we've started to use for power users is collecting public SSH
> keys and hosting them in the IPA server -- as long as IPA knows that the
> user "exists" in AD and has a roughly complete group membership list than
> logging in with SSH key instead of AD password bypasses the transient
> password checking failures and is very quick.

Another workaround (for the IPA masters at least) would be to put the
reachable AD DCs into a site and assign the IPA masters to this site.

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to