On Wed, Dec 07, 2016 at 11:34:12AM -0500, Chris Dagdigian wrote:
> 
> 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
> usern...@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 u...@nafta.company.com was shortened to u...@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.

The issues with the UPNs are far from odd and do not need fixing on the
AD side. As said before IPA-4.4 can handle them properly but the
ldap_user_principal/subdomain_inherit workaround for older versions can
be used for production.

> 
> 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.

The validation issue might have different reasons. One might be
https://fedorahosted.org/sssd/ticket/3103 where SSSD creates a wrong
Kerberos configuration snippet. Fixes are available for sssd-1.13 and
later. But there might be other reasons as well.

If you don't mind please send the krb5_child.log with debug_level=10
covering an authentication attempt with 'krb5_validate = true' and the
content of /var/lib/sss/pubconf/krb5.include.d/domain_realm_your_domain.

bye,
Sumit
> 
> 
> Regards,
> Chris
> 
> 
> 
> 
> 
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
  • ... List dedicated to discussions about use, configuration and deployment of the IPA server.
    • ... List dedicated to discussions about use, configuration and deployment of the IPA server.
      • ... List dedicated to discussions about use, configuration and deployment of the IPA server.
        • ... Sumit Bose
          • ... Chris Dagdigian
          • ... Chris Dagdigian
          • ... Chris Dagdigian
            • ... Sumit Bose
              • ... Chris Dagdigian
                • ... Sumit Bose
                • ... Chris Dagdigian
                • ... Sumit Bose

Reply via email to