> 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