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

Chris Dagdigian dag at sonsorol.org
Wed Dec 7 13:37:27 UTC 2016


Sumit,

Thank you so much for your assistance and eyeballs on the massive 
logset. I've repeatedly found the level of support on this list to be 
fantastic. Some day I'll have enough hands-on experience to repay in 
kind ...

We do actually use a different domain for the clients:

Our clients are "company-aws.org" while being managed by 
"company-idm.org" and talking to AD forests and many child domains in 
"company.org".

It's a fairly hairy setup driven mostly by "above my pay grade" distrust 
of IaaS cloud environments like AWS VPCs combined with existing use of 
Kerberos that we don't want to break. Hence putting IDM/IPA in a 
separate domain and realm altogether.

I actually DID see the "UPN used in the request .. differ" error 
messages all over the place.

I will try the workaround linked to below and report back.

Follow-up on the 4.4 release:

For people using CentOS/RHEL 7.x is it recommended to use  IPA 4.4 code 
in production? Our needs are pretty simple once you get beyond the 
complex AD environment - we just need simple SSH password authentication 
and a bit of RBAC feature for a small to midsize cloud footprint.  I'm 
guessing that running 4.4 if we have passwords working would not be all 
that risky for us. It really does seem like a large amount of recent IPA 
development has focused on AD integration so I'm actually fairly 
interested and motivated to step up from our 4.2 version.

Regards,
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  .
>
> HTH
>
> bye,
> Sumit




More information about the Freeipa-users mailing list