Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
I am seeing failures on the first time an AD group from a sub-domain is looked up by IPA clients. If I ssh as AD user on one IPA client and then try "getent group 'ADDOMAIN\ADGROUP'", I see nothing returned. If I do the same from a second IPA client, I see expected group lookup for ADGROUP returned.
First Clear MASTER cache and logs (for capturing smaller debugging data):
[root@ipaqa64vmf sssd]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start; sleep 5; for i in *.log; do cat /dev/null > $i; done
Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service
[root@ipaqa64vmf sssd]#
Fails on first try on CLIENT1:
[root@dell-pesc440-01 sssd]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start; sleep 5; for i in *.log; do cat /dev/null > $i; done
Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service
[root@dell-pesc440-01 sssd]#
[root@dell-pesc440-01 sssd]# ssh -l aduser1.qe $(hostname) echo success; getent group adgroup1.qe
aduser1.qe.test's password:
success
[root@dell-pesc440-01 sssd]#
Works on second try on CLIENT2:
[root@ipaqavmf sssd]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start; sleep 5; for i in *.log; do cat /dev/null > $i; done
Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service
[root@ipaqavmf sssd]# ssh -l aduser1.qe $(hostname) echo success; getent group adgroup1.qe
aduser1.qe.test's password:
success
adgroup1.qe:*:768201106:aduser1.qe
[root@ipaqavmf sssd]#
Version-Release number of selected component (if applicable):
sssd-1.11.2-65.el7.x86_64
ipa-server-3.3.3-28.el7.x86_64
How reproducible:
Very. I've also been able to reproduce it on a single IPA client by resetting SSSD cache and logging in and trying again.
Steps to Reproduce:
1. Setup IPA Master with Trust to AD Forest with child domain
2. AD Child Domain should have a custom user as a member of a custom security group
3. Setup IPA Client
4. Clear sssd cache and logs on all IPA hosts
cd /var/log/sssd
service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start
sleep 5
for i in *.log; do cat /dev/null > $i; done
5. SSH as AD User in AD Group
ssh -l <ADUSER>@<AD_CHILD_DOMAIN> $(hostname) echo succes; \
getent group <ADGROUP>@<AD_CHILD_DOMAIN>
Actual results:
Fails to see group on first try.
if you then reset sssd cache only on CLIENT and ssh and getent again, you see it work.
Expected results:
Should return normal group entry for ADGROUP
Additional info:
(In reply to Scott Poore from comment #0)
> Version-Release number of selected component (if applicable):
> ipa-server-3.3.3-28.el7.x86_64
> sssd-1.11.2-65.el7.x86_64
You are using outdated version of sssd on RHEL7.0. Could you explain me how is it possible?
This problem should be already fixed in up to date version of sssd 1.11.2-68.el7_0.5
Testing now with newer version. My repos apparently were not completely up to date.
I had forgotten about the 0day for RHEL7 release. Will update shortly. Do we have a bug that I can link this one to as a duplicate?
Thanks,
Scott
This is correct. When I tested with the newer version, I get this:
:: [ BEGIN ] :: Running 'getent group 'BOS2dgroup1''
adgroup1.qe:*:768201106:aduser1.qe
:: [ PASS ] :: Command 'getent group 'BOS2\adgroup1'' (Expected 0, got 0)
Description of problem: I am seeing failures on the first time an AD group from a sub-domain is looked up by IPA clients. If I ssh as AD user on one IPA client and then try "getent group 'ADDOMAIN\ADGROUP'", I see nothing returned. If I do the same from a second IPA client, I see expected group lookup for ADGROUP returned. First Clear MASTER cache and logs (for capturing smaller debugging data): [root@ipaqa64vmf sssd]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start; sleep 5; for i in *.log; do cat /dev/null > $i; done Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@ipaqa64vmf sssd]# Fails on first try on CLIENT1: [root@dell-pesc440-01 sssd]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start; sleep 5; for i in *.log; do cat /dev/null > $i; done Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@dell-pesc440-01 sssd]# [root@dell-pesc440-01 sssd]# ssh -l aduser1.qe $(hostname) echo success; getent group adgroup1.qe aduser1.qe.test's password: success [root@dell-pesc440-01 sssd]# Works on second try on CLIENT2: [root@ipaqavmf sssd]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start; sleep 5; for i in *.log; do cat /dev/null > $i; done Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@ipaqavmf sssd]# ssh -l aduser1.qe $(hostname) echo success; getent group adgroup1.qe aduser1.qe.test's password: success adgroup1.qe:*:768201106:aduser1.qe [root@ipaqavmf sssd]# Version-Release number of selected component (if applicable): sssd-1.11.2-65.el7.x86_64 ipa-server-3.3.3-28.el7.x86_64 How reproducible: Very. I've also been able to reproduce it on a single IPA client by resetting SSSD cache and logging in and trying again. Steps to Reproduce: 1. Setup IPA Master with Trust to AD Forest with child domain 2. AD Child Domain should have a custom user as a member of a custom security group 3. Setup IPA Client 4. Clear sssd cache and logs on all IPA hosts cd /var/log/sssd service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start sleep 5 for i in *.log; do cat /dev/null > $i; done 5. SSH as AD User in AD Group ssh -l <ADUSER>@<AD_CHILD_DOMAIN> $(hostname) echo succes; \ getent group <ADGROUP>@<AD_CHILD_DOMAIN> Actual results: Fails to see group on first try. if you then reset sssd cache only on CLIENT and ssh and getent again, you see it work. Expected results: Should return normal group entry for ADGROUP Additional info: