> On 20 May 2016, at 19:31, Erik Mackdanz <e...@infochimps.com> 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 <jhro...@redhat.com> 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
