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
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
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 -- email@example.com
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org