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:
It looks like we are unable to lookup Active Directory users after an AD Trust is re-established from IPA.
Simple id command is where I'm seeing the failure
Before re-establishing trust:
[root@yttrium ~]# id aduser1
uid=346213484(aduser1) gid=346213484(aduser1) groups=346213484(aduser1),346201110(adunigroup1),346201108(adgroup1),346201109(adgroup2),346200513(domain users)
After:
[root@yttrium ~]# id aduser1
id: aduser1: no such user
Version-Release number of selected component (if applicable):
ipa-server-4.5.0-21.el7_4.2.2.x86_64
sssd-1.15.2-50.el7_4.6.x86_64
How reproducible:
Unknown. Results in automated tests are varied but a manual reproduction was successful.
Steps to Reproduce:
1. Install ipa-server with DNS and setup trust with AD.
note: my test env has AD forest with a root and subdomain. and trust defaulted to one-way initially I think.
2. setup external group (not sure this step is actually necessary though but, I did it while trying to reproduce this).
ipa group-add --desc=0 bz1049533_external --external
ipa group-add --desc=0 bz1049533
ipa group-add-member bz1049533_external --external='adgroup1' --users='' --groups=''
3. Restart sssd and reset cache
systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd
4. Re-establish trust
ipa trust-add ipaad2012r2.test --admin Administrator --range-type=ipa-ad-trust --password --two-way=True
5. Lookup user
id aduser1
Actual results:
[root@yttrium ~]# ipa trust-add ipaad2012r2.test --admin Administrator --range-type=ipa-ad-trust --password --two-way=True
Active Directory domain administrator's password:
-------------------------------------------------
Re-established trust to domain "ipaad2012r2.test"
-------------------------------------------------
Realm name: ipaad2012r2.test
Domain NetBIOS name: IPAAD2012R2
Domain Security Identifier: S-1-5-21-547465014-1205121312-3291251547
Trust direction: Two-way trust
Trust type: Active Directory domain
Trust status: Established and verified
[root@yttrium ~]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start
Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service
[root@yttrium ~]# id aduser1
id: aduser1: no such user
Expected results:
I had expected to see the user returned like I did before I re-established the trust.
Additional info:
During the investigation of this issue two different error messages were seen.
The first is 'KDC policy rejects request' during the SASL bind (ldap_sasl_interactive_bind_s). This is a strong indication for a fail validation of the trust on the AD side. In the given setup it helped to clean up unused old trust information and conditional forwarders on the AD side. But there might be other reason preventing a proper validation on the AD side, e.g. other DNS issue, closed firewall ports for Windows/Samba services etc.
The second type of error message is 'In order to perform this operation a successful bind must be completed on the connection' after a LDAP search operation is send to the server (the bind was successful in this case). This message is a strong indication that the PAC is missing in the Kerberos ticket. It turned out that this happens if the KDC in the IPA server runs with multiple worker processes which is the default is the server has multiple CPUs. There is already code in IPA's KDC backend which make sure a AS_REQ form a HTTP/... principal triggers an update of the related configuration. But this happens only for the worker handling this request. All other workers (and all KDCs on other IPA servers) will continue to use the old configuration not aware of the trust. As a result only the updated worker will issue a PAC with an AS_REQ.
There is already code to update the configuration for TGS_REQ for principals form other domains, so eventually all workers might reread the configuration but this might take some time.
As a work-around the KDCs can be restarted manually on all IPA servers.
Based on the comments above I move this ticket to the IPA component.
Comment 16Florence Blanc-Renaud
2018-01-08 16:28:00 UTC