You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1514061
Description of problem:
Setup: IdM with AD Trust. A Posix group 'ad_admins' (GID 732000006) exists with
one member 'ad_admins_external'. The member of the external group is the
Windows Domain Admins group. There also exists a Windows Domain User 'aduser'
with UID/GID 702801104.
Without any ID override or domain resolution order defined, 'id
aduser@windows.mylab.local' gives the following output:
# id aduser@windows.mylab.local
uid=702801104(aduser@windows.mylab.local)
gid=702801104(aduser@windows.mylab.local) groups=702801104(aduser@windows.mylab
.local),732000005(ad_users),702800513(domain users@windows.mylab.local)
Now I define an ID override in the Default Trust View for the 'aduser' to
change the GID to 732000006:
# ipa idoverrideuser-add 'Default Trust View' aduser@windows.mylab.local
--gidnumber=732000006
I clean the cache and verify that the user now uses the GID from the ID
override:
# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/* /var/log/sssd/*; systemctl
start sssd
# id aduser@windows.mylab.local
uid=702801104(aduser@windows.mylab.local) gid=732000006(ad_admins)
groups=732000006(ad_admins),732000005(ad_users),702800513(domain
users@windows.mylab.local)
This works as expected.
Now I change the domain resolution order so that I don't have to use the domain
name when I refer to the 'aduser' account:
# ipa config-mod
--domain-resolution-order=windows.mylab.local:linux.mylab.local
# ipa config-show|grep -i resolution
Domain resolution order: windows.mylab.local:linux.mylab.local
I clean the cache and verify again that the 'aduser' account still uses the GID
from the ID override:
# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd
# id aduser
uid=702801104(aduser@windows.mylab.local)
gid=732000006(aduser@windows.mylab.local) groups=732000006(aduser@windows.mylab
.local),732000005(ad_users@linux.mylab.local),702800513(domain
users@windows.mylab.local)
As we can see, the user still uses the correct GID from the ID override
(732000006), but the GID is resolved to the wrong group name ('aduser' instead
of 'ad_admins').
Also using the domain with the user name doesn't change this behaviour:
# id aduser@windows.mylab.local
uid=702801104(aduser@windows.mylab.local)
gid=732000006(aduser@windows.mylab.local) groups=732000006(aduser@windows.mylab
.local),732000005(ad_users@linux.mylab.local),702800513(domain
users@windows.mylab.local)
Looking into the SSSD logs, shows that SSSD indeed tries to resolve the GID
732000005 (adusers) rather than 732000006 (ad_admins):
(Thu Nov 16 16:03:19 2017) [sssd[be[linux.mylab.local]]]
[dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][id
number=732000005]
When I remove the domain resolution order, everything works as expected again:
# ipa config-mod --domain-resolution-order=
# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd
# id aduser@windows.mylab.local
uid=702801104(aduser@windows.mylab.local) gid=732000006(ad_admins)
groups=732000006(ad_admins),732000005(ad_users),702800513(domain
users@windows.mylab.local)
In the SSSD logs we can now also see that SSSD tries to resolve the correct GID
(732000006):
(Thu Nov 16 16:06:07 2017) [sssd[be[linux.mylab.local]]]
[dp_get_account_info_handler] (0x0200): Got request for
[0x2][BE_REQ_GROUP][idnumber=732000006]
Version-Release number of selected component (if applicable):
sssd-1.15.2-50.el7_4.6.x86_64
ipa-server-4.5.0-21.el7_4.2.2.x86_64
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/3595
Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1514061
Comments
Comment from jhrozek at 2017-12-05 15:24:38
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-12-05 15:25:15
Metadata Update from @jhrozek:
Comment from fidencio at 2017-12-05 21:57:39
Metadata Update from @fidencio:
Comment from fidencio at 2017-12-05 21:57:54
PR: #464
Comment from jhrozek at 2017-12-13 23:08:07
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-12-13 23:19:43
Metadata Update from @jhrozek:
Comment from jhrozek at 2018-03-20 13:42:16
Metadata Update from @jhrozek:
Comment from fidencio at 2018-05-11 17:44:13
master:
cf4f5e0
Comment from fidencio at 2018-05-11 17:44:40
Metadata Update from @fidencio:
The text was updated successfully, but these errors were encountered: