[Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Chris Dagdigian]

Our problem is largely solved but we are using some "do not use in 
production!" settings so I wanted to both recap our solution and ask 
some follow up questions.

Our setup:
-------------
  - FreeIPA 4.2 running on CentOS-7 in AWS VPC
  - Edge-case split DNS setup. Our cloud clients are "company-aws.org" 
while IPA is "company-ipa.org" realm/domain
  - Massive need to authenticate against AD Forest COMPANY.COM which 
includes a ton of child domains (NAFTA.COMPANY.COM, etc.)

Problem
-----------
- AD users are recognized and can be enumerated as long as I use 
username at NAFTA.COMPANY.COM
- "su - <user>" works as root to become the AD user
- All methods that require password check (SSH login mainly) failed

The breakthrough was the advice from Sumit to add the 
ldap_user_principal and subdomain_inherit settings. The core problem on 
our end seemed to be issues with having the AD user UPN get sorted out. 
Something was failing when user at NAFTA.COMPANY.COM was shortened to 
user at COMPANY.COM and we saw the recurring error about " ... UPN is quite 
different ... "  in the sssd domain logs.


Solution (Server Side)
-----------------------------
In /etc/sssd/sssd.conf:
  ldap_user_principal = nosuchattr
  subdomain_inherit = ldap_user_principal
  krb5_validate = false


Solution (IPA client side)
--------------------------------
In /etc/sssd/sssd.conf:
  krb5_validate = false


I think the main problem is obvious. Even Sumit was clear to state that 
"krb5_validate = false" should be used for testing only.

However if we remove that setting password checking breaks.


So the basic "what next question" for the experts is:


1. Do we chase down whatever config error we have that requires 
krb5_validate=false ?
2. Or do we assume that that problem is related to the UPN problem and 
related AD-across-child-domains that appear to be resolved in IPA-4.4? I 
keep getting the sense that massive AD-related things have been improved 
recently in 4.3 and 4.4

My gut feeling is that it is our odd UPN issue that is breaking things 
so rather than bend over backwards to try to figure out why 
krb5_validate=false on our IPA-4.2 setup I'm sort of leaning towards 
trying to go for an upgrade to IPA-4.4 and hope that whatever issue 
forced us to disable krb5_validate is resolved in the new updates.

Am I being stupid (again?)  Obviously the krb5_validate=false setting 
needs to be fixed. Just not sure if I should work on a fix within 4.2 or 
move to 4.4 and see if it gets resolved as part of other changes.


Regards,
Chris