Bug 1471966

Summary: IPA client identity lookups failing for trusted AD Users
Product: Red Hat Enterprise Linux 7 Reporter: Matt.Agresta <Matt.Agresta>
Component: sssdAssignee: SSSD Maintainers <sssd-maint>
Status: CLOSED DUPLICATE QA Contact: sssd-qe <sssd-qe>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.3CC: grajaiya, jhrozek, lslebodn, mkosek, mzidek, pbrezina, tscherf
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-07-18 08:47:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
client sssd domain logs none

Description Matt.Agresta@kuehne-nagel.com 2017-07-17 19:37:25 UTC 
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Install/Enroll Client: ipa-client-install -U --domain ipa.us.int.kn --force-join --mkhomedir -p admin -w PASSWORD
2. Run identity lookup on AD user: id Matt.Agresta.int.kn
3.

Actual results:
id: Matt.Agresta.int.kn: no such user

Expected results:
Group listings

Additional info:
With Debugging turned up to 9, I can see the issue is the Data Provider going offline after returning an error message:

(Mon Jul 17 15:36:24 2017) [sssd[nss]] [get_client_cred] (0x4000): Client creds: euid[0] egid[0] pid[7549].
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [get_client_cred] (0x0020): SELINUX_getpeercon failed [-1][Unknown error -1].
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7fc649957460][25]
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected!
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7fc649957460][25]
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1].
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1].
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7fc649957460][25]
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7fc649957460][25]
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17][SSS_NSS_GETPWNAM] with input [Matt.Agresta.int.kn].
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'Matt.Agresta.int.kn' matched expression for domain 'usa.win.int.kn', user is Matt.Agresta
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [Matt.Agresta] from [usa.win.int.kn]
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/usa.win.int.kn/matt.agresta.int.kn]
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [matt.agresta.int.kn]
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7fc64994d8e0

(Mon Jul 17 15:36:24 2017) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7fc64994d9a0

(Mon Jul 17 15:36:24 2017) [sssd[nss]] [ldb] (0x4000): Running timer event 0x7fc64994d8e0 "ltdb_callback"

(Mon Jul 17 15:36:24 2017) [sssd[nss]] [ldb] (0x4000): Destroying timer event 0x7fc64994d9a0 "ltdb_timeout"

(Mon Jul 17 15:36:24 2017) [sssd[nss]] [ldb] (0x4000): Ending timer event 0x7fc64994d8e0 "ltdb_callback"

(Mon Jul 17 15:36:24 2017) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a LOCAL view, continuing with provided values.
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7fc64963a820:1:matt.agresta.int.kn.int.kn]
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [usa.win.int.kn][0x1][BE_REQ_USER][1][name=matt.agresta.int.kn:-]
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [sbus_add_timeout] (0x2000): 0x7fc64994e800
(Mon Jul 17 15:36:24 2017) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7fc64963a820:1:matt.agresta.int.kn.int.kn]
(Mon Jul 17 15:36:39 2017) [sssd[nss]] [sbus_remove_timeout] (0x2000): 0x7fc64994e800
(Mon Jul 17 15:36:39 2017) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 0x7fc649943a50
(Mon Jul 17 15:36:39 2017) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching.
(Mon Jul 17 15:36:39 2017) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 12 error message: Cannot allocate memory
(Mon Jul 17 15:36:39 2017) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider
Error: 3, 12, Cannot allocate memory
Comment 2 Jakub Hrozek 2017-07-17 19:55:15 UTC 
Based on this:
(Mon Jul 17 15:36:39 2017) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider
Error: 3, 12, Cannot allocate memory

Please check if any of the groups the user is a member of contains the @-sign.
Comment 3 Matt.Agresta@kuehne-nagel.com 2017-07-17 20:35:48 UTC 
Hey Jakub,

This appears to be the issue, when I removed that group the looks up work. As I am not sure how large the fallout would be from renaming this group, is there a work around for this?

Regards,
Matt
Comment 4 Jakub Hrozek 2017-07-18 08:47:59 UTC 
You can try setting the alternative re_expression as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1383520 (I'm going to close this BZ as a duplicate of #1383520 as well)

*** This bug has been marked as a duplicate of bug 1383520 ***
Comment 5 Matt.Agresta@kuehne-nagel.com 2017-07-18 13:37:17 UTC 
Thanks,

Unfortunately the filter in that report does not work for me. All of the groups causing issues have the same patter in them (groupname). I have tried several different patterns with no luck, could you tell me what I am doing wrong?

(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$)|((?P<name>.+@example.com)@(?P<domain>.+$)))
Comment 6 Jakub Hrozek 2017-07-18 18:46:04 UTC 
(In reply to Matt.Agresta from comment #5)
> Thanks,
> 
> Unfortunately the filter in that report does not work for me. All of the
> groups causing issues have the same patter in them (groupname).
> I have tried several different patterns with no luck, could you tell me what
> I am doing wrong?
> 
> (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.
> +$))|(^(?P<name>[^@\\]+)$)|((?P<name>.+@example.com)@(?P<domain>.+$)))

Not really, can you post your config file and logs, please? btw it is not guaranteed that this regex will suffice on its own, there is also parsing done on the IPA server side by the IPA server itself. But I guess in your case the groups made it to the client, so provided the correct regex, it client should be able to parse them..
Comment 7 Matt.Agresta@kuehne-nagel.com 2017-07-18 18:57:41 UTC 
I think I figured out the reg_ex part (at least partly). I can now resolve the user, but am having trouble getting secondary groups. Judging from other's issues maybe its schema related? I am trying to use ldapsearch to verify the groups but not having much luck with the command syntax.

sssd.conf
[domain/ipa.us.int.kn]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.us.int.kn
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = lxmatazan200s.us.int.kn
chpass_provider = ipa
ipa_server = lxipaazan100s.ipa.us.int.kn
dns_discovery_domain = ipa.us.int.kn
re_expression = (((?P<name>.+@.+)@(?P<domain>.+))|((?P<name>[^@]+)@?(?P<domain>[^@]*$)))
use_fully_qualified_names = True

debug_level = 9
[sssd]
services = nss, sudo, pam, ssh


debug_level = 9

domains = ipa.us.int.kn
[nss]
debug_level = 9
homedir_substring = /home


I will attach a log as well.
Comment 8 Matt.Agresta@kuehne-nagel.com 2017-07-18 19:01:44 UTC 
Created attachment 1300621 [details]
client sssd domain logs
Comment 9 Matt.Agresta@kuehne-nagel.com 2017-07-19 15:39:49 UTC 
I commented out "use_fully_qualified_names = True" and it seems to be working consistently. Unfortunately my HBAC rule is denying AD users but this is most likely a separate issue.
Comment 10 Matt.Agresta@kuehne-nagel.com 2017-07-19 16:13:01 UTC 
Disregard my last comment.

Commenting out "use_fully_qualified_names = True" did improve the situation. If I do a lookup now I see about half of my groups, and the groups appear to change between lookup. The log looks the same I have attached, could this be a timeout issue?