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 <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