[Freeipa-users] Mostly working trust, SSH failure
Jakub Hrozek
jhrozek at redhat.com
Sun May 22 11:48:28 UTC 2016
> 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
More information about the Freeipa-users
mailing list