Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts
On Thu, Dec 08, 2016 at 11:37:25AM -0500, Chris Dagdigian wrote: > > Massive thank you; will test ASAP. > > We mainly have to support CentOS/RHEL-6 and CentOS/RHEL-7 clients. Is there > any established guidance on upgrading SSSD in these environments? Some sort > of trusted repo where RPMs are built? I can hit the wiki and website but > figured I'd ask as well. Not sure what other dependencies the SSSD framework > may have or pull in. You might want to have a look at https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/ . Lukas is doing a great job here in providing test-builds of the latest versions release in Fedora for other/older platforms. But please note those are test-build. You have to wait until CentOS release the 7.3 packages to have an 'official' sssd-1.14 build. HTH bye, Sumit > > Sumit Bose wrote: > > } > > > > at the very beginning of /etc/krb5.conf before and include or includedir > > directives should fix it. With the broken configuration libkrb5 thinks > > that there direct trust between NAFTA.COMPANY.ORG and COMPANYIDM.ORG > > which is not the case, everything has to go via COMPANY.ORG because > > that's the domain which trusts COMPANYIDM.ORG. > > > > Updating SSSD to a version with the fix might help as well. > > > > HTH > -- 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
Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts
Massive thank you; will test ASAP. We mainly have to support CentOS/RHEL-6 and CentOS/RHEL-7 clients. Is there any established guidance on upgrading SSSD in these environments? Some sort of trusted repo where RPMs are built? I can hit the wiki and website but figured I'd ask as well. Not sure what other dependencies the SSSD framework may have or pull in. Sumit Bose wrote: } at the very beginning of /etc/krb5.conf before and include or includedir directives should fix it. With the broken configuration libkrb5 thinks that there direct trust between NAFTA.COMPANY.ORG and COMPANYIDM.ORG which is not the case, everything has to go via COMPANY.ORG because that's the domain which trusts COMPANYIDM.ORG. Updating SSSD to a version with the fix might help as well. HTH -- 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
Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts
On Thu, Dec 08, 2016 at 09:29:34AM -0500, Chris Dagdigian wrote:
>
> Sumit Bose wrote:
> > > > 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.
>
> Thanks Sumit,
>
> Info you requested is attached. These logs are from a client machine. I
> confirmed that I could not authenticate with krb5_validate = True and that I
> could authenticate when I switched krb5_validate=false. I set the value to
> "True", turned up debug logging to 10 and then stopped SSSD service after my
> 3 login tries to try to constrain the log volume.
>
> Still ended up with 1200+ lines in krb5_child.log though
>
> Here is the info you requested (sanitized)
>
> URL to krb5_child.log since it is pretty lengthy:
> -
> http://chrisdag.me/krb5_child.log.txt
>
>
> And we actually had 2 domain_realm* files which is I think due to our
> difference in DNS for client hostnames vs DNS for the IPA server:
> Our CAPATH info does look like that SSSD issue you mentioned (ticket 3103)
> ...
>
>
> This is domain_realm_companyaws_org:
> --
> [domain_realm]
> .COMPANY.ORG = COMPANY.ORG
> COMPANY.ORG = COMPANY.ORG
> .EAME.COMPANY.ORG = EAME.COMPANY.ORG
> EAME.COMPANY.ORG = EAME.COMPANY.ORG
> .APAC.COMPANY.ORG = APAC.COMPANY.ORG
> APAC.COMPANY.ORG = APAC.COMPANY.ORG
> .LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
> LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
> .NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
> NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
> [capaths]
> COMPANY.ORG = {
> COMPANYAWS.ORG = COMPANY.ORG
> }
> COMPANYAWS.ORG = {
> COMPANY.ORG = COMPANY.ORG
> }
> EAME.COMPANY.ORG = {
> COMPANYAWS.ORG = COMPANY.ORG
> }
> COMPANYAWS.ORG = {
> EAME.COMPANY.ORG = COMPANY.ORG
> }
> APAC.COMPANY.ORG = {
> COMPANYAWS.ORG = COMPANY.ORG
> }
> COMPANYAWS.ORG = {
> APAC.COMPANY.ORG = COMPANY.ORG
> }
> LATAM.COMPANY.ORG = {
> COMPANYAWS.ORG = COMPANY.ORG
> }
> COMPANYAWS.ORG = {
> LATAM.COMPANY.ORG = COMPANY.ORG
> }
> NAFTA.COMPANY.ORG = {
> COMPANYAWS.ORG = COMPANY.ORG
> }
> COMPANYAWS.ORG = {
> NAFTA.COMPANY.ORG = COMPANY.ORG
> }
>
>
>
>
> And this is domain_realm_companyidm_org:
>
> [domain_realm]
> .COMPANY.ORG = COMPANY.ORG
> COMPANY.ORG = COMPANY.ORG
> .EAME.COMPANY.ORG = EAME.COMPANY.ORG
> EAME.COMPANY.ORG = EAME.COMPANY.ORG
> .APAC.COMPANY.ORG = APAC.COMPANY.ORG
> APAC.COMPANY.ORG = APAC.COMPANY.ORG
> .LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
> LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
> .NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
> NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
> [capaths]
> COMPANYAWS.ORG = {
> COMPANYIDM.ORG = COMPANYAWS.ORG
> }
> COMPANYIDM.ORG = {
> COMPANYAWS.ORG = COMPANYAWS.ORG
> }
> COMPANY.ORG = {
> COMPANYIDM.ORG = COMPANY.ORG
> }
> COMPANYIDM.ORG = {
> COMPANY.ORG = COMPANY.ORG
> }
> EAME.COMPANY.ORG = {
> COMPANYIDM.ORG = COMPANY.ORG
> }
> COMPANYIDM.ORG = {
> EAME.COMPANY.ORG = COMPANY.ORG
> }
> APAC.COMPANY.ORG = {
> COMPANYIDM.ORG = COMPANY.ORG
> }
> COMPANYIDM.ORG = {
> APAC.COMPANY.ORG = COMPANY.ORG
> }
> LATAM.COMPANY.ORG = {
> COMPANYIDM.ORG = COMPANY.ORG
> }
> COMPANYIDM.ORG = {
> LATAM.COMPANY.ORG = COMPANY.ORG
> }
> NAFTA.COMPANY.ORG = {
> COMPANYIDM.ORG = COMPANY.ORG
> }
> COMPANYIDM.ORG = {
> NAFTA.COMPANY.ORG = COMPANY.ORG
> }
Yes, you are right the capaths are wrong.
Adding:
[capaths]
COMPANYAWS.ORG = {
COMPANYIDM.ORG = COMPANYAWS.ORG
}
COMPANYIDM.ORG = {
COMPANYAWS.ORG = COMPANYAWS.ORG
COMPANY.ORG = COMPANY.ORG
EAME.COMPANY.ORG = COMPANY.ORG
APAC.COMPANY.ORG = COMPANY.ORG
LATAM.COMPANY.ORG = COMPANY.ORG
NAFTA.COMPANY.ORG = COMPANY.ORG
}
COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
EAME.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
APAC.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
LATAM.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
NAFTA.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
at the very beginning of /etc/krb5.conf before and include or includedir
directives should fix it. With the broken configuration libkrb5 thinks
that there direct trust between NAFTA.COMPANY.ORG and COMPANYIDM.ORG
which is not the case, everything has to go via COMPANY.ORG because
that's the domain which trusts COMPANYIDM.ORG.
Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts
Sumit Bose wrote:
> 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.
Thanks Sumit,
Info you requested is attached. These logs are from a client machine. I
confirmed that I could not authenticate with krb5_validate = True and
that I could authenticate when I switched krb5_validate=false. I set
the value to "True", turned up debug logging to 10 and then stopped SSSD
service after my 3 login tries to try to constrain the log volume.
Still ended up with 1200+ lines in krb5_child.log though
Here is the info you requested (sanitized)
URL to krb5_child.log since it is pretty lengthy:
-
http://chrisdag.me/krb5_child.log.txt
And we actually had 2 domain_realm* files which is I think due to our
difference in DNS for client hostnames vs DNS for the IPA server:
Our CAPATH info does look like that SSSD issue you mentioned (ticket
3103) ...
This is domain_realm_companyaws_org:
--
[domain_realm]
.COMPANY.ORG = COMPANY.ORG
COMPANY.ORG = COMPANY.ORG
.EAME.COMPANY.ORG = EAME.COMPANY.ORG
EAME.COMPANY.ORG = EAME.COMPANY.ORG
.APAC.COMPANY.ORG = APAC.COMPANY.ORG
APAC.COMPANY.ORG = APAC.COMPANY.ORG
.LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
.NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
[capaths]
COMPANY.ORG = {
COMPANYAWS.ORG = COMPANY.ORG
}
COMPANYAWS.ORG = {
COMPANY.ORG = COMPANY.ORG
}
EAME.COMPANY.ORG = {
COMPANYAWS.ORG = COMPANY.ORG
}
COMPANYAWS.ORG = {
EAME.COMPANY.ORG = COMPANY.ORG
}
APAC.COMPANY.ORG = {
COMPANYAWS.ORG = COMPANY.ORG
}
COMPANYAWS.ORG = {
APAC.COMPANY.ORG = COMPANY.ORG
}
LATAM.COMPANY.ORG = {
COMPANYAWS.ORG = COMPANY.ORG
}
COMPANYAWS.ORG = {
LATAM.COMPANY.ORG = COMPANY.ORG
}
NAFTA.COMPANY.ORG = {
COMPANYAWS.ORG = COMPANY.ORG
}
COMPANYAWS.ORG = {
NAFTA.COMPANY.ORG = COMPANY.ORG
}
And this is domain_realm_companyidm_org:
[domain_realm]
.COMPANY.ORG = COMPANY.ORG
COMPANY.ORG = COMPANY.ORG
.EAME.COMPANY.ORG = EAME.COMPANY.ORG
EAME.COMPANY.ORG = EAME.COMPANY.ORG
.APAC.COMPANY.ORG = APAC.COMPANY.ORG
APAC.COMPANY.ORG = APAC.COMPANY.ORG
.LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
.NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
[capaths]
COMPANYAWS.ORG = {
COMPANYIDM.ORG = COMPANYAWS.ORG
}
COMPANYIDM.ORG = {
COMPANYAWS.ORG = COMPANYAWS.ORG
}
COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
COMPANYIDM.ORG = {
COMPANY.ORG = COMPANY.ORG
}
EAME.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
COMPANYIDM.ORG = {
EAME.COMPANY.ORG = COMPANY.ORG
}
APAC.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
COMPANYIDM.ORG = {
APAC.COMPANY.ORG = COMPANY.ORG
}
LATAM.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
COMPANYIDM.ORG = {
LATAM.COMPANY.ORG = COMPANY.ORG
}
NAFTA.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
COMPANYIDM.ORG = {
NAFTA.COMPANY.ORG = COMPANY.ORG
}
--
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
Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts
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 - " 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
Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts
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 - " 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. 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 -- 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
Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts
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 u...@nafta.company.org which then gets shortened to u...@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 (u...@nafta.company.org -> u...@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 . -- 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
Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts
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 (u...@nafta.company.org -> u...@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 -- 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
Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts
On Tue, Dec 06, 2016 at 03:17:33PM -0500, List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: > > Appreciate the assistance! > > Is there a better debug level balance than 10 for this sort of situation? > The domain logs were several hundred MBs by the time I started looking for > useful info if there is a different level I can use that would better at > producing actionable error/log messages I'll gladly switch ... > > > List dedicated to discussions about use, configuration and deployment of the > IPA server. wrote: > > > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005 [main] (0x0400): > > > > krb5_child started. > > > > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005 [unpack_buffer] > > > > (0x1000): total buffer size: [158] > > > > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005 [unpack_buffer] > > > > (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [false] > > > > enterprise principal [false] offline [true] UPN [u...@company.org] > > > >^^^ > > > > The backend switch to offline mode, please send the SSSD domain logs > > around this time as well. If possible please start about 5 minutes > > earlier. > > > > bye, > > Sumit > > I searched through the massive SSSD domain logs and had trouble finding the > right area so here are the lines surrounding my own username when I tried to > authenticate via SSH using AD credentials: > > ... > ... > [sss_krb5_expire_callback_func] (0x2000): exp_time: [2742397] > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406 [get_and_save_tgt] > (0x0100): TGT validation is disabled. > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406 > [sss_get_ccache_name_for_principal] (0x4000): Location: > [KEYRING:persistent:1843770609] > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406 > [sss_get_ccache_name_for_principal] (0x4000): tmp_ccname: > [KEYRING:persistent:1843770609:krb_ccache_OVBc5zF] > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406 [create_ccache] > (0x4000): Initializing ccache of type [KEYRING] > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406 [create_ccache] > (0x4000): CC supports switch > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406 [create_ccache] > (0x4000): returning: 0 > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406 > [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the > same, none will be deleted. > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406 [k5c_send_data] > (0x0200): Received error code 0 > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406 > [pack_response_packet] (0x2000): response packet size: [144] > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406 [k5c_send_data] > (0x4000): Response sent. > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406 [main] (0x0400): > krb5_child completed successfully ... > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 > [sss_krb5_expire_callback_func] (0x2000): exp_time: [2742394] > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 [get_and_save_tgt] > (0x0100): TGT validation is disabled. > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 > [sss_get_ccache_name_for_principal] (0x4000): Location: > [KEYRING:persistent:1843770609] > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 > [sss_get_ccache_name_for_principal] (0x4000): tmp_ccname: > [KEYRING:persistent:1843770609:krb_ccache_OVBc5zF] > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 [create_ccache] > (0x4000): Initializing ccache of type [KEYRING] > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 [create_ccache] > (0x4000): CC supports switch > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 [create_ccache] > (0x4000): returning: 0 > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 > [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the > same, none will be deleted. > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 [k5c_send_data] > (0x0200): Received error code 0 > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 > [pack_response_packet] (0x2000): response packet size: [144] > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 [k5c_send_data] > (0x4000): Response sent. > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417 [main] (0x0400): > krb5_child completed successfully > > 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 (u...@nafta.company.org -> u...@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 'Tue Dec 6 19:57:11' and 'Tue Dec 6 19:57:14'. If that's the case updating to 4.4 would help because in this release IPA can forward the enterprise
Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts
2016-12-06
Thread
List dedicated to discussions about use, configuration and deployment of the IPA server.
Appreciate the assistance! Is there a better debug level balance than 10 for this sort of situation? The domain logs were several hundred MBs by the time I started looking for useful info if there is a different level I can use that would better at producing actionable error/log messages I'll gladly switch ... List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005 [main] (0x0400): > krb5_child started. > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005 [unpack_buffer] > (0x1000): total buffer size: [158] > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005 [unpack_buffer] > (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [false] > enterprise principal [false] offline [true] UPN [u...@company.org] ^^^ The backend switch to offline mode, please send the SSSD domain logs around this time as well. If possible please start about 5 minutes earlier. bye, Sumit I searched through the massive SSSD domain logs and had trouble finding the right area so here are the lines surrounding my own username when I tried to authenticate via SSH using AD credentials: /var/log/sssd/sssd_DOMAIN.log (Sanitized) --- (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [be_req_set_domain] (0x0400): Changing request domain from [company-idm.org] to [NAFTA.COMPANY.ORG] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f78cb39e850 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f78cb3b7200 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): Running timer event 0x7f78cb39e850 "ltdb_callback" (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): Destroying timer event 0x7f78cb3b7200 "ltdb_timeout" (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): Ending timer event 0x7f78cb39e850 "ltdb_callback" (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaUserOverride)(uid=t859531))]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_print_server] (0x2000): Searching 10.127.64.11 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaUserOverride)(uid=t859531))][cn=Default Trust View,cn=views,cn=accounts,dc=companyidm,dc=org]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 118 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_op_add] (0x2000): New operation 118 timeout 60 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_result] (0x2000): Trace: sh[0x7f78cb2224a0], connected[1], ops[0x7f78cb39efa0], ldap[0x7f78cb1cfb40] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_op_destructor] (0x2000): Operation 117 finished (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-299502267-823518204-725345543-160433))]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success) (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_result] (0x2000): Trace: sh[0x7f78cb2224a0], connected[1], ops[0x7f78cb39efa0], ldap[0x7f78cb1cfb40] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_op_destructor] (0x2000): Operation 118 finished (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ipa_get_ad_override_done] (0x4000): No override found with filter
Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts
2016-12-06
Thread
List dedicated to discussions about use, configuration and deployment of the IPA server.
On Tue, Dec 06, 2016 at 12:45:18PM -0500, List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: > > This is a new thread related to one I started today about upgrading FreeIPA > software before continuing troubleshooting work ... > > New post here so I don't pollute the other thread. > > > > Looking for additional eyeballs or tips on this ongoing problem. The short > summary > is we can't check passwords for AD users. > > SSSD is running in debug-10 mode and we have tons of logs > > I've got 2 interesting things to trace down, would be interested in feedback > on > which may be best to concentrate on ... > > > 1. In the SAMBA logs there are very clear and interesting "message=Cannot > contact any KDC for realm 'COMPANY-IDM.ORG'" > which seems very straightforward and interesting you can ignore those, samba is not involved in the authentication. > > 2. However the SSSD logs contain more worrisome messages about TGT ticket > errors > > > Should I concentrate on the samba logs that talk about being unable to find > the KDC? > That seems more straightforward at the moment. > > > Thanks! > > -Chris > > > > > ... > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005 [main] (0x0400): > krb5_child started. > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005 [unpack_buffer] > (0x1000): total buffer size: [158] > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005 [unpack_buffer] > (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [false] > enterprise principal [false] offline [true] UPN [u...@company.org] ^^^ The backend switch to offline mode, please send the SSSD domain logs around this time as well. If possible please start about 5 minutes earlier. bye, Sumit -- 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
