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

[Chris Dagdigian]

Confirmed that adding the following to /etc/sssd/ssd.conf on the SERVER 
fixed SSH password checks on the server itself!

ldap_user_principal = nosuchattr
subdomain_inherit = ldap_user_principal

The core problem does appear to be the "... UPN is quite different" 
error when we try to login as user at NAFTA.COMPANY.ORG which then gets 
shortened to user at COMPANY.ORG. It's hard to read the volume of 
debug_level 10 logs but it's clear that it's getting hung up with 
principals when talking to the remote AD servers.

I can now login to the IPA server with my standard AD credentials which 
has been impossible until just now.

However no luck on IPA clients. Can you confirm that the above sssd.conf 
workaround is for the IPA server only as the thread you linked to 
indicates or is this a change I should push down to clients? I'm going 
to build some fresh clients just in case.

And knowing that this workaround seems to be getting close to totally 
resolving our issue would you recommend IPA-4.4 for our environment 
where we have lots of AD trusts in play combined with DNS-DOMAIN 
differences between the IPA realm and the managed clients? Or is it 
better to stick with the workaround settings + the IPA-4.2 release that 
comes with CentOS/RHEL-7?

Thanks!

Chris


Sumit Bose wrote:
> Both authentications where successful against the backend. For the logs
> it looks like you use an alternative domain suffix on the AD side so
> that all user if other domains in the forest can use the forest root
> suffix as realm, in the user principal (user at NAFTA.COMPANY.ORG  ->
> user at COMPANY.ORG).
>
> I would expect that there are messages like "UPN used in the request
> ...differ by more than just the case." in the domain log at 'TueDec  6
> 19:57:11'  and 'TueDec  6 19:57:14'.
>
> If that's the case updating to4.4  would help because in this release
> IPA can forward the enterprise principals properly and SSSD will not
> reject the changed principal because sSSD will be aware of the change.
>
> But there are workarounds to make it work with your version as well,
> please see e.g. the suggestion from
> https://www.redhat.com/archives/freeipa-users/2016-May/msg00205.html  .