Hi Alexander
On Tue, Mar 10, 2015 at 12:08 PM, Alexander Bokovoy <aboko...@redhat.com> wrote: > On Tue, 10 Mar 2015, Traiano Welcome wrote: >> >> However, I'm still not able to authenticate via the ssh->sssd path (I >> cn get kerberos tickets for ad users via cli though), so I think that >> incorrect dc discovery is not really the issue here. Instead, it seem >> the ldap query against the discovered AD domain controller is failing >> with some kid of policy related error: >> >> Here's a snippet what we're seeing in the IPA master sssd logs during >> an a client connection attempt: >> >> --- >> . >> . >> . >> (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >> (0x0100): Executing sasl bind mech: gssapi, user: >> host/lolospr-idm-mstr.idmdc2.com >> (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >> (0x0020): ldap_sasl_bind failed (-2)[Local error] >> (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >> (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI >> Error: Unspecified GSS failure. Minor code may provide more >> information (KDC policy rejects request)] > > When AD says "KDC policy rejects request" it means that trust is not > working well -- AD DC was unable to complete trust validation when it > was established. See another emails around the trust last week or so, > they have details on how to debug this. This is probably the case, however, I'd like to drill down further to see exactly what part of the trust is broken, because it seems the trust was established without error (using "ipa trust-add"), and I seem to be able to get trust information with " ipa trust-show": Re-adding the trusts: --- [root@loldc2-idm-mstr ~]# ipa trust-add --type=ad lol.com --admin admin --password Active directory domain administrator's password: ------------------------------------------ Re-established trust to domain "lol.com" ------------------------------------------ Realm name: lol.com Domain NetBIOS name: LOL Domain Security Identifier: S-1-5-21-4090660947-345563186-3527492641 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified [root@loldc2-idm-mstr ~]# --- Using trust show: --- [root@loldc2-idm-mstr sssd]# ipa trust-show Realm name: LOL.COM Realm name: lol.com Domain NetBIOS name: LOL Domain Security Identifier: S-1-5-21-4090660947-345563186-3527492641 Trust direction: Two-way trust Trust type: Active Directory domain --- I can see that not all is well with the trusts because when I test with wbinfo, I get this: --- [root@loldc2-idm-mstr ~]# wbinfo --verbose -n 'LOL\Domain Admins' failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND Could not lookup name LOL\Domain Admins --- Looking at the samba logs with debug turned up, I get something potentially enlightening in the message "NT_STATUS_ACCESS_DENIED" ... However, the question is to pinpoint if this is due to an AD-side policy issue, or due to some weirdness on the IPA end of things: --- . . . [2015/03/10 17:02:46.934072, 3, pid=6917, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_lookupname.c:69(winbindd_lookupname_send) lookupname LOL\Domain Admins [2015/03/10 17:02:46.934190, 1, pid=6917, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) wbint_LookupName: struct wbint_LookupName in: struct wbint_LookupName domain : * domain : 'LOL' name : * name : 'DOMAIN ADMINS' flags : 0x00000000 (0) [2015/03/10 17:02:46.934532, 50, pid=6917, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7facefb10430 [2015/03/10 17:02:46.934696, 50, pid=6917, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7facefb10430 [2015/03/10 17:02:46.934812, 1, pid=6917, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) wbint_LookupName: struct wbint_LookupName out: struct wbint_LookupName type : * type : SID_NAME_USE_NONE (0) sid : * sid : S-0-0 result : NT_STATUS_ACCESS_DENIED [2015/03/10 17:02:46.935174, 5, pid=6917, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_lookupname.c:104(winbindd_lookupname_recv) Could not convert sid S-0-0: NT_STATUS_ACCESS_DENIED [2015/03/10 17:02:46.935281, 10, pid=6917, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:755(wb_request_done) wb_request_done[8382:LOOKUPNAME]: NT_STATUS_ACCESS_DENIED --- (I can also kinit directly from the cli on the master using an AD user and get a ticker from the Active Directory kdc, which is confusing because it implies trust relationship working !): --- [root@loldc2-idm-mstr samba]# kinit trai...@lol.com Password for trai...@lol.com: [root@loldc2-idm-mstr samba]# [root@loldc2-idm-mstr samba]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_Hrq3EtZ Default principal: trai...@lol.com Valid starting Expires Service principal 03/10/2015 17:21:49 03/11/2015 03:21:49 krbtgt/lol....@lol.com renew until 03/11/2015 17:21:45 [root@loldc2-idm-mstr samba]# --- So the question is: Are there further diagnostics I can do to drill down further into how/where trust is broken, and what the NT_STATUS_ACCESS_DENIED from the dc is being triggered in response to? -- 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