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.
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?
Thanks!
Chris
On Thu, Nov 16, 2017 at 12:10:01PM -0500, Chris Dagdigian via FreeIPA-users wrote:
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 https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html.
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 trusted domains.
HTH
bye, Sumit
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?
Thanks!
Chris
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
freeipa-users@lists.fedorahosted.org
-
Chris Dagdigian -
Sumit Bose