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 <jhro...@redhat.com> wrote:
>
>> 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

Reply via email to