Re: [Freeipa-users] Mostly working trust, SSH failure [SOLVED]
On Mon, May 23, 2016 at 4:26 PM, Rob Crittenden wrote: > https://lists.fedorahosted.org/archives/list/sssd-de...@lists.fedorahosted.org/thread/TUZ6ZWLRZ6QSMUHV44PRT75T6OVBGILK/ This was exactly our issue. We were able to build a patched version, and our forest AD user could log in successfully. Many thanks Jakub, Rob, and the rest of the freeipa/sssd communities! Erik -- 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] Mostly working trust, SSH failure [SOLVED]
On Wed, May 25, 2016 at 09:43:55AM -0500, Erik Mackdanz wrote: > On Mon, May 23, 2016 at 4:26 PM, Rob Crittenden wrote: > > https://lists.fedorahosted.org/archives/list/sssd-de...@lists.fedorahosted.org/thread/TUZ6ZWLRZ6QSMUHV44PRT75T6OVBGILK/ > > This was exactly our issue. We were able to build a patched version, > and our forest AD user could log in successfully. > > Many thanks Jakub, Rob, and the rest of the freeipa/sssd communities! > Erik I'm glad it works now, although the credit goes to Sumit who actually found and fixed the issue. FWIW, I just submitted the fixed build for RHEL-7.2 testing, if that goes well, the fix should appear in the next RHEL-7.2 batch of updates.. -- 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] Mostly working trust, SSH failure
Erik Mackdanz wrote: 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. https://lists.fedorahosted.org/archives/list/sssd-de...@lists.fedorahosted.org/thread/TUZ6ZWLRZ6QSMUHV44PRT75T6OVBGILK/ rob 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 wrote: On 20 May 2016, at 19:31, Erik Mackdanz 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 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 (Th
Re: [Freeipa-users] Mostly working trust, SSH failure
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 wrote: > >> On 20 May 2016, at 19:31, Erik Mackdanz 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 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:
Re: [Freeipa-users] Mostly working trust, SSH failure
> On 20 May 2016, at 19:31, Erik Mackdanz 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 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
Re: [Freeipa-users] Mostly working trust, SSH failure
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, 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 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
Re: [Freeipa-users] Mostly working trust, SSH failure
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