For the bug you mentioned ([1], downstream [2]), there is a patch but it's not publicly accessible. Are you able post the patch to this list? It may help us determine if we are directly affected.
Thanks, Erik [1] https://fedorahosted.org/sssd/ticket/3015 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1336688 On Sun, May 22, 2016 at 6:48 AM, Jakub Hrozek <[email protected]> wrote: > >> On 20 May 2016, at 19:31, Erik Mackdanz <[email protected]> wrote: >> >> Thanks Jakub, >> >> Yes, the "marking subdomain ... inactive" portion is below. >> >> There are failures in resolving the Global Catalog via SRV, but what >> I've read says that should be okay because we fall back to the >> SID<->UID mapping. With dig, I can reproduce sssd's finding that >> those SRV records don't exist. Is the DNS failure as fatal as it >> appears? > > Yes, I think that's the issue. I don't think we fall back to LDAP lookups. > (btw we have a bug where we use the domain name, not the forest name for GC > lookups SRV query..) > >> >> Yes, we can kinit AD users. We can also 'getent' AD users and groups >> (at least the group we authorized in our trust). >> >> Does it matter that the user we used to establish the trust was later >> demoted? (Was domain admin, now regular user). >> >> Cheers, >> Erik >> >> >> [ipa_srv_ad_acct_retried] (0x0400): Sudomain re-set, will retry lookup >> [be_fo_reset_svc] (0x1000): Resetting all servers in service >> na.bazzlegroup.com >> [set_srv_data_status] (0x0100): Marking SRV lookup of service >> 'na.bazzlegroup.com' as 'neutral' >> [set_server_common_status] (0x0100): Marking server >> 'deda9w1004.na.bazzlegroup.com' as 'name not resolved' >> [fo_set_port_status] (0x0100): Marking port 389 of server >> 'deda9w1004.na.bazzlegroup.com' as 'neutral' >> [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP >> [fo_set_port_status] (0x0400): Marking port 389 of duplicate server >> 'deda9w1004.na.bazzlegroup.com' as 'neutral' >> [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP >> [set_srv_data_status] (0x0100): Marking SRV lookup of service >> 'na.bazzlegroup.com' as 'neutral' >> [set_server_common_status] (0x0100): Marking server >> 'usbe9w2003.na.bazzlegroup.com' as 'name not resolved' >> [fo_set_port_status] (0x0100): Marking port 389 of server >> 'usbe9w2003.na.bazzlegroup.com' as 'neutral' >> [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP >> [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP >> [fo_set_port_status] (0x0400): Marking port 389 of duplicate server >> 'usbe9w2003.na.bazzlegroup.com' as 'neutral' >> [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account >> [sdap_id_op_connect_step] (0x4000): beginning to connect >> [fo_resolve_service_send] (0x0100): Trying to resolve service >> 'gc_na.bazzlegroup.com' >> [get_port_status] (0x1000): Port status of port 0 for server '(no >> name)' is 'not working' >> [fo_resolve_service_send] (0x0020): No available servers for service >> 'gc_na.bazzlegroup.com' >> [be_resolve_server_done] (0x1000): Server resolution failed: 5 >> [sdap_id_op_connect_done] (0x0400): Failed to connect to server, but >> ignore mark offline is enabled. >> [sdap_id_op_connect_done] (0x4000): notify error to op #1: 5 >> [Input/output error] >> [be_mark_dom_offline] (0x1000): Marking subdomain na.bazzlegroup.com offline >> [be_mark_subdom_offline] (0x1000): Marking subdomain >> na.bazzlegroup.com as inactive >> [ipa_srv_ad_acct_lookup_done] (0x0040): ipa_get_*_acct request failed: >> [1432158262]: Subdomain is inactive. >> [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: >> 1432158262 >> [sdap_id_op_destroy] (0x4000): releasing operation connection >> >> On Fri, May 20, 2016 at 2:02 AM, Jakub Hrozek <[email protected]> wrote: >>> On Thu, May 19, 2016 at 05:18:43PM -0500, Erik Mackdanz wrote: >>>> Hello, >>>> >>>> I've set up a one-way trust to an Active Directory domain. Things >>>> seem to roughly work, but something's missing. >>>> >>>> Can any kind soul spot a problem with my configuration, or advise on >>>> how to further troubleshoot? >>>> >>>> Facts: >>>> >>>> - An AD user gets 'Access denied' when SSH'ing by password to the >>>> FreeIPA host. This is my concern. >>>> >>>> - This AD user has not been locked out. >>>> >>>> - getent passwd succeeds for the AD user >>>> >>>> - A FreeIPA user can successfully SSH by password to the same FreeIPA >>>> host. >>>> >>>> - That FreeIPA user can then successfully kinit as the AD user (the >>>> same AD user denied above) >>>> >>>> - HBAC is set to the default allow_all rule, which is enabled. >>>> Running the HBAC Test tool on the AD user confirms that they are >>>> authorized for sshd. >>>> >>>> This tells me something is awry in sssd.conf or sshd_config or pam.d >>>> or HBAC. >>>> >>>> Thanks, >>>> Erik >>>> >>>> I've got sssd debug to 9. Here's some output: >>>> >>>> >>> >>> [...] >>> >>>> (Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]] >>>> [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account >>>> (Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]] >>>> [be_mark_dom_offline] (0x1000): Marking subdomain na.bazzlegroup.com >>>> offline >>>> (Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]] >>>> [be_mark_subdom_offline] (0x4000): Subdomain already inactive >>>> (Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]] >>> >>> Here it looks like sssd previously had issues connectying to AD and went >>> offline. Can you search the logs a bit earlier for the first occurence of >>> "Marking subdomain xxx as offline" ? Can you kinit as that user? >>> >>> -- >>> 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 >> >> -- >> 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 > -- 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
