Bug 1644902
| Summary: | SSSD not resolving gid for users with id overrides in Idm | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Louis Abel <tucklesepk> | ||||||||||
| Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> | ||||||||||
| Status: | CLOSED NOTABUG | QA Contact: | sssd-qe <sssd-qe> | ||||||||||
| Severity: | high | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 7.6 | CC: | dchen, ddas, grajaiya, hkhot, jhrozek, kechoi, kludhwan, lslebodn, mzidek, nsuryawa, pbrezina, sbose, sgoveas, sssd-maint, thalman, tmihinto, tscherf, tucklesepk | ||||||||||
| Target Milestone: | rc | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | sync-to-jira | ||||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2020-03-13 06:21:38 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
Louis Abel
2018-10-31 20:59:44 UTC
Created attachment 1499649 [details]
SSSD configuration for clients
SSSD configuration for clients
can you add sssd debug logs, too? See https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html Created attachment 1499654 [details]
sssd debug logs from IPA master
As requested, these are debug logs for sssd. This is from an IPA master.
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? Created attachment 1502219 [details]
ID Override Screenshot
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? 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. 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.
Created attachment 1502288 [details]
sssd debug logs 2.0.0 client
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. The offending commit is cf4f5e031ecbdfba0b55a4f69a06175a2e718e67 Upstream ticket: https://pagure.io/SSSD/sssd/issue/3877 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. 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 (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" |