On Thu, Nov 16, 2017 at 12:10:01PM -0500, Chris Dagdigian via FreeIPA-users
> The most fragile and user-angering aspect of our complex IPA setup in AWS is
> when user AD password checks mysteriously fail and deny login. All of the
> troubleshooting stuff works fine - user is recognized as valid, ipa hbactest
> all work fine but the user gets permission denied when logging in.
> Right now my only fix is converting users over to SSH keybased logins with
> the IPA server holding the public key -- that works great. Restarting sssd a
> few times and waiting 10 minutes also usually resolves the issue.
> We *suspect* the password check failure is because this large organization
> has 100+ domain controllers scattered in networks and datacenters all over
> the place and we think that maybe SSSD is DNS resolving via _SVR_ records a
> domain controller that is unreachable or unknown to our cloud nACLs and
> security controls -- or maybe a domain controller that just flat out refuses
> to talk to us.
> I've seen on this list mentions of really cool AD integration improvements
> like being able to have more than one AD domain vs the existing "Default
> domain" that requires our users to login with fully qualified
> <username>@<DOMAIN>.COMPANY.ORG as well as mentions that future versions of
> SSSD would allow us to pin our communication to known/named AD controllers?
> I think the basic advice from the IPA community was that this stuff was
> showing up in modern sssd releases and that we just had to wait a bit for
> the updated sssd code to show up in distro repos.
For the user names you might want to have a look at
For using specific DCs in trusted domains please have a look at the
'TRUSTED DOMAIN SECTION' of man sssd.conf. There you can find
information how to set ad_server, ad_site and some other options for
> Did I understand things correctly? Are we at the point now with IPA and SSD
> upgrades where we could possibly pin our AD traffic to named controllers?
> And maybe also address the AD domain search issue as well?
> FreeIPA-users mailing list -- firstname.lastname@example.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
FreeIPA-users mailing list -- email@example.com
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org