RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1644902 - SSSD not resolving gid for users with id overrides in Idm
Summary: SSSD not resolving gid for users with id overrides in Idm
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.6
Hardware: All
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: sssd-qe
URL:
Whiteboard: sync-to-jira
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-31 20:59 UTC by Louis Abel
Modified: 2023-09-07 19:29 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-13 06:21:38 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
SSSD configuration for clients (530 bytes, text/plain)
2018-10-31 21:10 UTC, Louis Abel 		no flags Details
sssd debug logs from IPA master (7.98 MB, application/x-gzip)
2018-10-31 21:40 UTC, Louis Abel 		no flags Details
ID Override Screenshot (26.67 KB, image/png)
2018-11-05 21:41 UTC, Louis Abel 		no flags Details
sssd debug logs 2.0.0 client (41.05 KB, application/x-gzip)
2018-11-06 07:04 UTC, Louis Abel 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4867 0 None closed SSSD not resolving user's group to name if user's GID number was overriden 2021-02-02 12:14:47 UTC

Description Louis Abel 2018-10-31 20:59:44 UTC 
Description of problem:
SSSD version upgraded from 1.16.0 to 1.16.2 when updating to 7.6. Our servers are FreeIPA clients where FreeIPA has a trust with AD. Since the upgrade, now all systems with 1.16.2 report this when logging in:

id: cannot find name for group ID 11111
[louis.abel@diurne ~]$

I believe this matters; we are using id views for our AD users. Example object:

dn: ipaanchoruuid=...,cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=example,dc=com
objectClass: ipaOverrideAnchor
objectClass: top
objectClass: ipaUserOverride
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
gidNumber: 11111
homeDirectory: /home/louis.abel
ipaAnchorUUID:: . . .
ipaOriginalUid: louis.abel.com
loginShell: /bin/bash
uidNumber: 11111

For accounts that do not have id views, this problem does NOT occur. Example.

[root@entl02 ~]# su - daniel.white
Creating home directory for daniel.white.com.
[daniel.white.com@entl02 ~]$

Version-Release number of selected component (if applicable):
sssd-1.16.2-13.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Update to 7.6/sssd 1.16.2 or run Fedora 28/29 using sssd 2.0 - must be an IPA client
2. id username / su - username

Actual results:
GID is not found: id: cannot find name for group ID 11111

Expected results:
ID's are resolved.

Additional info:

I am also noticing that this is occurring on Fedora's release of SSSD, which are also clients in the IPA domain. 

[nazu@nocturne 01:49 PM ~]$ rpm -q sssd
sssd-2.0.0-3.fc29.x86_64
[nazu@nocturne 01:49 PM ~]$ su - louis.abel
Last login: Wed Oct 31 13:44:24 MST 2018 on pts/12
id: cannot find name for group ID 25439
[louis.abel@diurne ~]$ id
uid=111111(louis.abel) gid=11111 groups=11111
Comment 2 Louis Abel 2018-10-31 21:10:57 UTC 
Created attachment 1499649 [details]
SSSD configuration for clients

SSSD configuration for clients
Comment 3 Jakub Hrozek 2018-10-31 21:12:19 UTC 
can you add sssd debug logs, too? See https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
Comment 4 Louis Abel 2018-10-31 21:40:29 UTC 
Created attachment 1499654 [details]
sssd debug logs from IPA master

As requested, these are debug logs for sssd. This is from an IPA master.
Comment 5 Jakub Hrozek 2018-11-05 20:58:14 UTC 
What should the GID 25439 resolve to? In the logs I see:

(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][idnumber=25439]
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [dp_attach_req] (0x0400): DP Request [Account #9]: New request. Flags [0x0001].
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [dp_attach_req] (0x0400): Number of active DP request: 1
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sss_domain_get_state] (0x1000): Domain ipa.example.com is Active
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sss_domain_get_state] (0x1000): Domain ad.example.com is Active
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sss_domain_get_state] (0x1000): Domain ipa.example.com is Active
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sss_domain_get_state] (0x1000): Domain ad.example.com is Active
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaGroupOverride)(gidNumber=25439))].

---> SSSD tried to find an override with gidNumber 25439

(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sdap_print_server] (0x2000): Searching 172.20.23.22:389
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaGroupOverride)(gidNumber=25439))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=example,>
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 85
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sdap_op_add] (0x2000): New operation 85 timeout 6
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55cf85cbe990], connected[1], ops[0x55cf85d46840], ldap[0x55cf85ca91a0]
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sdap_op_destructor] (0x2000): Operation 85 finished
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaGroupOverride)(gidNumber=25439))].

--> but no such override was found

(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sss_domain_get_state] (0x1000): Domain ipa.example.com is Active
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sss_domain_get_state] (0x1000): Domain ad.example.com is Active
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sss_domain_get_state] (0x1000): Domain ipa.example.com is Active
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [sss_domain_get_state] (0x1000): Domain ad.example.com is Active
(Wed Oct 31 21:17:51 2018) [sssd[be[ipa.example.com]]] [ad_account_can_shortcut] (0x0080): Mapping ID [25439] to SID failed: [IDMAP domain not found]

---> and then sssd realized that this GID can't come from the IPA domain so it shortcut the request

I also can't reproduce the working behaviour with the old version, the GID is never found (as I'd expect it to, unless I define either an override or a group that has that GID).

So I have some follow up questions:
 - is there in your environment an override or a group with this GID?
 - can you share logs from the older, working version?
Comment 6 Louis Abel 2018-11-05 21:41:28 UTC 
Created attachment 1502219 [details]
ID Override Screenshot
Comment 7 Louis Abel 2018-11-05 21:41:43 UTC 
The intention of the overrides in the default trust view was to make it so as we transitioned from LDAP over to IPA, the current ID's that we already had established in LDAP would come over, instead of them becoming the long string of numbers and then permissions are now out of order. So the point was to make the transition easy on us without having to make a group for each and every person in idm or in AD. 

In my tests, I tried 11111 and also 25439 for example (and I copied and pasted from the wrong terminal, so it was kind of misleading, I apologize), and I'm running into the same issue of the GID stating that it's not found. As soon as the override is gone from 'default trust view' there's no issue.

The attached screenshot shows what I have for example in the override. I haven't changed these overrides at all since I applied them in idm 4.5.4. And when I had applied them then, 25439 would come up as 'louis.abel' without any other fuss. There's no groups or otherwise that I would be doing overrides for. The trust is not using POSIX and no POSIX attributes are on any AD object.

I don't know if I have logs from the working older version. Would logs from a client with an older SSSD version suffice (1.16.0, 1.13.3)? Or are you needing sssd logs that would be on an idm replica?
Comment 8 Louis Abel 2018-11-06 00:00:36 UTC 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/id-views

Is this documentation not accurate? I was under the impression that the way I was doing it was the correct way to override the UID and GID. For example...

invalid 'identifier': You are trying to reference a magic private group which is not allowed to be overridden. Try overriding the GID attribute of the corresponding user instead.
Comment 9 Louis Abel 2018-11-06 07:03:00 UTC 
I went to my CentOS test cluster which is still running the following versions:

[root@np-ipa01 ~]# rpm -q sssd ipa-server
sssd-1.16.0-19.el7_5.8.x86_64
ipa-server-4.5.4-10.el7.centos.4.4.x86_64

I created a trust with a 2016 test domain.

[root@np-ipa01 ~]# ipa trust-add
Realm name: test.angelsofclockwork.net
Active Directory domain administrator: administrator
Active Directory domain administrator's password:
-------------------------------------------------------------------
Added Active Directory trust for realm "test.angelsofclockwork.net"
-------------------------------------------------------------------
  Realm name: test.angelsofclockwork.net
  Domain NetBIOS name: TEST
  Domain Security Identifier: S-1-5-21-1528527773-84445775-4266398922
  Trust direction: Trusting forest
  Trust type: Active Directory domain
  Trust status: Established and verified

[root@np-ipa01 ~]# id administrator.net
uid=942400500(administrator.net) gid=942400500(administrator.net) groups=942400500(administrator.net),942400512(domain admins.net),942400519(enterprise admins.net),942400520(group policy creator owners.net),942400518(schema admins.net),942400513(domain users.net)

These are the ID's. I put in an ID override.

[root@np-ipa01 ~]# ipa idoverrideuser-add --uid=13133 --gidnumber=13133 'Default Trust View' administrator.net
-----------------------------------------------------------------
Added User ID override "administrator.net"
-----------------------------------------------------------------
  Anchor to override: administrator.net
  UID: 13133
  GID: 13133

I check the ID...

[root@np-ipa01 ~]# id administrator.net
uid=13133(administrator.net) gid=13133(administrator.net) groups=13133(administrator.net),942400512(domain admins.net),942400519(enterprise admins.net),942400520(group policy creator owners.net),942400518(schema admins.net),942400513(domain users.net)

This is the behavior I'm expecting where the UID and GID are the same and both reference the user and their private group. In IPA 4.6.4 and SSSD sssd-1.16.2-13.el7.x86_64 as part of RHEL 7.6 and Fedora SSSD 2.0.0, this is no longer the case. 

[root@tester ~]# ipa-client-install --realm IPA.ANGELSOFCLOCKWORK.NET --domain ipa.angelsofclockwork.net --no-ntp                                                                                                                                 
This program will set up FreeIPA client.                                                                                                                                                                                                             
Version 4.7.0                                                                                                                                                                                                                                        
                                                                                                                                                                                                                                                     
Discovery was successful!                                                                                                                                                                                                                            
Client hostname: tester.angelsofclockwork.net                                                                                                                                                                                                        
Realm: IPA.ANGELSOFCLOCKWORK.NET                                                                                                                                                                                                                     
DNS Domain: ipa.angelsofclockwork.net                                                                                                                                                                                                                
IPA Server: np-ipa01.ipa.angelsofclockwork.net                                                                                                                                                                                                       
BaseDN: dc=ipa,dc=angelsofclockwork,dc=net                                                                                                                                                                                                           
                                                                                                                                                                                                                                                     
Continue to configure the system with these values? [no]: yes                                                                                                                                                                                        
Skipping chrony configuration                                                                                                                                                                                                                        
User authorized to enroll computers: louis.abel                                                                                                                                                                                                      
Password for louis.abel.NET:                                                                                                                                                                                                   
Successfully retrieved CA cert                                                                                                                                                                                                                       
    Subject:     CN=Certificate Authority,O=IPA.ANGELSOFCLOCKWORK.NET                                                                                                                                                                                
    Issuer:      CN=Certificate Authority,O=IPA.ANGELSOFCLOCKWORK.NET                                                                                                                                                                                
    Valid From:  2017-07-11 05:00:16                                                                                                                                                                                                                 
    Valid Until: 2037-07-11 05:00:16                                                                                                                                                                                                                 
                                                                                                                                                                                                                                                     
Enrolled in IPA realm IPA.ANGELSOFCLOCKWORK.NET                                                                                                                                                                                                      
Created /etc/ipa/default.conf                                                                                                                                                                                                                        
Configured sudoers in /etc/nsswitch.conf                                                                                                                                                                                                             
Configured /etc/sssd/sssd.conf                                                                                                                                                                                                                       
Configured /etc/krb5.conf for IPA realm IPA.ANGELSOFCLOCKWORK.NET                                                                                                                                                                                    
Systemwide CA database updated.                                                                                                                                                                                                                      
Hostname (tester.angelsofclockwork.net) does not have A/AAAA record.                                                                                                                                                                                 
Failed to update DNS records.                                                                                                                                                                                                                        
Missing A/AAAA record(s) for host tester.angelsofclockwork.net: 10.100.0.159.                                                                                                                                                                        
Missing reverse record(s) for address(es): 10.100.0.159.                                                                                                                                                                                             
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub                                                                                                                                                                                         
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub                                                                                                                                                                                           
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub                                                                                                                                                                                             
Could not update DNS SSHFP records.                                                                                                                                                                                                                  
SSSD enabled                                                                                                                                                                                                                                         
Configured /etc/openldap/ldap.conf                                                                                                                                                                                                                   
Configured /etc/ssh/ssh_config                                                                                                                                                                                                                       
Configured /etc/ssh/sshd_config                                                                                                                                                                                                                      
Configuring ipa.angelsofclockwork.net as NIS domain.                                                                                                                                                                                                 
Client configuration complete.                                                                                                                                                                                                                       
The ipa-client-install command was successful                                                                                                                                                                                                        
[root@tester ~]# id administrator.net                                                                                                                                                                                      
uid=13133(administrator.net) gid=13133 groups=13133,942400512(domain admins.net),942400519(enterprise admins.net),942400520(group policy creator owners.n
et),942400518(schema admins.net),942400513(domain users.net)

[root@np-ipa01 db]# ldbsearch -H cache_ipa.angelsofclockwork.net.ldb name=Administrator.net originalADuidNumber originalADgidNumber uidNumber gidNumber
asq: Unable to register control with rootdse!
# record 1
dn: name=Administrator.net,cn=users,cn=test.angelsofclockwork.net,cn=sysdb
originalADuidNumber: 942400500
originalADgidNumber: 942400500
uidNumber: 13133
gidNumber: 13133

The newer SSSD versions appear to be having this issue.
Comment 10 Louis Abel 2018-11-06 07:04:35 UTC 
Created attachment 1502288 [details]
sssd debug logs 2.0.0 client
Comment 11 Jakub Hrozek 2018-11-07 10:47:56 UTC 
Thank you, I can now reproduce the correct behaviour with the old version and the bug with the new version. You were right the steps are correct.

Let me bisect the changes to see where we broke this use-case.
Comment 12 Jakub Hrozek 2018-11-07 11:29:07 UTC 
The offending commit is cf4f5e031ecbdfba0b55a4f69a06175a2e718e67
Comment 13 Jakub Hrozek 2018-11-07 12:22:49 UTC 
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3877
Comment 18 Sumit Bose 2020-02-05 19:14:43 UTC 
Hi,

after some testing I would say that the current behavior is expected and the old behavior of sssd-1.16.0 was not planned [1] and only worked accidentally. The can be seen by trying to lookup the group with an empty cache. 'getent group 11111' will return nothing and 'getent group louis.abel' will return the group but with the original UID value of the user. Only if the user is looked up before the group the behavior is consistent but might change if the user entry expires and the next request is to lookup the group by name.

Currently SSSD expects that there is a real group with a matching GID (or override GID) if the GID of a user is overwritten. There is currently no support for handling user-private groups automatically with id-overrides. To make it work you have to add a group with the GID 11111 or create an id-override for an existing group with the GID 11111.

Since having user-private groups is a useful feature my suggestion would be to change this ticket into an RFE/Future Feature and plan and design it and make sure there is no conflict with other features in this area like e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1649464.

HTH

bye,
Sumit

[1] The behavior is even a bug which prevented expected usage as described in https://bugzilla.redhat.com/show_bug.cgi?id=1514061.
Comment 20 Sumit Bose 2020-03-13 06:21:38 UTC 
Hi,

based on comment #18 I close this ticket.

Please note, if you add a primary GID to a user id-override a group with the same GID must exist.

bye,
Sumit
Comment 21 Ding-Yi Chen 2020-09-01 07:38:45 UTC 
(In reply to Sumit Bose from comment #18)

> Currently SSSD expects that there is a real group with a matching GID (or
> override GID) if the GID of a user is overwritten. There is currently no
> support for handling user-private groups automatically with id-overrides. To
> make it work you have to add a group with the GID 11111 or create an
> id-override for an existing group with the GID 11111.
> 


More precisely, the GID need to be in the LDAP in IPA.
Local GIDs also do not work.

In addition, the sss_override won't work when IPA is in place, 
otherwise, it shows:

 
"Other than LOCAL view already exists in domain example.com"
Note You need to log in before you can comment on or make changes to this bug.