[Freeipa-users] Mostly working trust, SSH failure

Mon May 23 21:26:45 UTC 2016

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-devel@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 <jhrozek at redhat.com> wrote:
>>
>>> On 20 May 2016, at 19:31, Erik Mackdanz <erik at 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 <jhrozek at 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
>>
>