Bug 1139361
| Summary: | RHEL6.6 ssh as admin on ipa server fails after 389-ds-base update | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Scott Poore <spoore> | ||||||
| Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Sankar Ramalingam <sramling> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 6.6 | CC: | jgalipea, jhrozek, ksiddiqu, lkrispen, nkinder, nsoman, rmeggins, xdong | ||||||
| Target Milestone: | rc | Keywords: | TestBlocker | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2014-09-11 18:43:16 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: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 990143, 1109379 | ||||||||
| Attachments: |
|
||||||||
Created attachment 935431 [details]
dirsrv/ logs
Fyi, marking testblocker because it was preventing ipa-replica-install from successfully passing the ipa-replica-conncheck. Hi Scott, I think you had no problem with 389-ds-base-1.2.11.15-42. 1.2.11.15-43 was built with this patch on top of 1.2.11.15-42. * Fri Sep 5 2014 Noriko Hosoi <nhosoi> - 1.2.11.15-43 - Release 1.2.11.15-43 - Resolves: #1112702 - Broken dereference control with the FreeIPA 4.0 ACIs (#47885) Looking into the access log in /var/log/dirsrv/slapd-TESTRELM-TEST, it ends with ABANDON. The timestamp matches "Sep 8 13:07:20 rhel6-1 sshd[3351]: pam_sss(sshd:account): Access denied for user admin: 4 (System error)" (although, since the DS access logs are buffered, the timestamp is not very accurate.) [08/Sep/2014:13:07:20 -0500] conn=11 op=16 SRCH base="cn=accounts,dc=testrelm,dc=test" scope=2 filter="(&(objectClass=ipaHost)(fqdn=rhel6-1.testrelm.test))" attrs="objectClass cn fqdn serverHostName memberOf ipaSshPubKey ipaUniqueID" [08/Sep/2014:13:07:20 -0500] conn=11 op=16 RESULT err=0 tag=101 nentries=1 etime=0 notes=P [08/Sep/2014:13:07:20 -0500] conn=11 op=17 SRCH base="fqdn=rhel6-1.testrelm.test,cn=computers,cn=accounts,dc=testrelm,dc=test" scope=0 filter="(objectClass=*)" attrs="objectClass cn memberOf ipaUniqueID" [08/Sep/2014:13:07:20 -0500] conn=11 op=17 RESULT err=0 tag=101 nentries=1 etime=0 notes=P [08/Sep/2014:13:07:20 -0500] conn=11 op=18 ABANDON targetop=NOTFOUND msgid=17 No other errors nor operation failures are reported in the log files. I wonder why the DS received ABANDON request. And deref (fixed by the 47885 patch) is involved in the operations there? Ludwig, do you have any idea? no. The change from .42 to .43 seems to be only the fix for #47885 and it changes the behaviour of the deref plugin (as requested by sssd). Now we have the message: Sep 8 13:07:20 rhel6-1 sssd[be[testrelm.test]]: dereference processing failed : No such file or directory So to me it looks like sssd is nothandling the change, but we need someone from sssd to look into it what is the IPA version you are using ? [root@rhel6-1 ~]# rpm -q ipa-server sssd ipa-server-3.0.0-42.el6.x86_64 sssd-1.11.6-4.el6.x86_64 Created attachment 935745 [details]
/var/log/sssd dir
I thought the issue fixed in #47885 was only visible with the new acis in IPA 4.0. So the question is if .43 is needed in that env ? Chances are this is caused by the same SSSD bug as 1139044. Scott, can you re-test with an older SSSD version? 1.11.6-25 or older would do. sssd-1.11.6-4.el6.x86_64 is the version I had on the server where I saw the problem. Is that too old? FYI, I tried with sssd-1.11.6-25.el6.x86_64 and see the same issue still. So the DS behaviour changed to something SSSD doesn't expect and I'm not sure which part behaves correctly. It's apparently fallout of the dereference changes. We are dereferencing a memberof attribute of a host object that has no memberof attribute. With the old version, whenever we searched and used the deref control, we got the deref control back in the reply. That's not the case with the new version and the SSSD dereference code relies on getting the control back. Which of the two is the expected behavior? Here is the diff between the ldapsearches with DS-42 and 43:
diff new-version old-version
12c12,13
< krbLastSuccessfulAuth: 20140910090956Z
---
> control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAAA
> krbLastSuccessfulAuth: 20140910090146Z
The krbLastSuccessfulAuth changed b/c I was authenticating as the host.
(In reply to Jakub Hrozek from comment #14) > So the DS behaviour changed to something SSSD doesn't expect and I'm not > sure which part behaves correctly. It's apparently fallout of the > dereference changes. > > We are dereferencing a memberof attribute of a host object that has no > memberof attribute. > > With the old version, whenever we searched and used the deref control, we > got the deref control back in the reply. That's not the case with the new > version and the SSSD dereference code relies on getting the control back. > > Which of the two is the expected behavior? This is part of the change, when removing entries returned with the deref control because there is no access I noticed that the list could be empty and then did not return the control - maybe this is incorrect. Will try to check the RFC and ask my team. I can revert this change and always return the control, even if it is empty. But reading this part of the spec:
>>
The control value may contain dereference attribute values without
any dereferenced attribute values, as detailed in Section 2.3. The
control semantics does not specify whether this is a consequence of a
dangling link or of the application of access restrictions on the
values of the attributes to be dereferenced.
<<
it should also be ok to return references to entries without access.
This issue is a regression caused by the fix for bug 1112702. Closing this as a duplicate, as we'll handle fixing this in the original bug. *** This bug has been marked as a duplicate of bug 1112702 *** |
Description of problem: On RHEL6.6 server built from 9/03 source, I installed IPA server. Then to update, I updated 389-ds-base to version 389-ds-base-1.2.11.15-43.el6.x86_64. I can no longer log in as admin on the IPA server: [root@rhel6-1 ~]# ssh admin@$(hostname) "hostname; id" admin.test's password: Connection closed by UNKNOWN Version-Release number of selected component (if applicable): 389-ds-base-1.2.11.15-43.el6.x86_64 How reproducible: always Steps to Reproduce: 1. Install RHEL6.6 version with 389-ds-base-1.2.11.15-42 2. ipa-server-install 3. ssh admin@$(hostname) works so far 4. update 389-ds-base to 1.2.11.15-43 3. ssh admin@$(hostname) Actual results: fails on the ssh after updating 389-ds-base [root@rhel6-1 ~]# yum update 389-ds-base Loaded plugins: product-id, subscription-manager This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package 389-ds-base.x86_64 0:1.2.11.15-42.el6 will be updated ---> Package 389-ds-base.x86_64 0:1.2.11.15-43.el6 will be an update --> Processing Dependency: 389-ds-base-libs = 1.2.11.15-43.el6 for package: 389-ds-base-1.2.11.15-43.el6.x86_64 --> Running transaction check ---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-42.el6 will be updated ---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-43.el6 will be an update --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================= Package Arch Version Repository Size ======================================================================================================= Updating: 389-ds-base x86_64 1.2.11.15-43.el6 beaker-rhel-6.6-latest-server 1.5 M Updating for dependencies: 389-ds-base-libs x86_64 1.2.11.15-43.el6 beaker-rhel-6.6-latest-server 417 k Transaction Summary ======================================================================================================= Upgrade 2 Package(s) Total download size: 1.9 M Is this ok [y/N]: y Downloading Packages: (1/2): 389-ds-base-1.2.11.15-43.el6.x86_64.rpm | 1.5 MB 00:02 (2/2): 389-ds-base-libs-1.2.11.15-43.el6.x86_64.rpm | 417 kB 00:00 ------------------------------------------------------------------------------------------------------- Total 524 kB/s | 1.9 MB 00:03 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Updating : 389-ds-base-libs-1.2.11.15-43.el6.x86_64 1/4 Updating : 389-ds-base-1.2.11.15-43.el6.x86_64 2/4 Cleanup : 389-ds-base-1.2.11.15-42.el6.x86_64 3/4 Cleanup : 389-ds-base-libs-1.2.11.15-42.el6.x86_64 4/4 Verifying : 389-ds-base-libs-1.2.11.15-43.el6.x86_64 1/4 Verifying : 389-ds-base-1.2.11.15-43.el6.x86_64 2/4 Verifying : 389-ds-base-1.2.11.15-42.el6.x86_64 3/4 Verifying : 389-ds-base-libs-1.2.11.15-42.el6.x86_64 4/4 Updated: 389-ds-base.x86_64 0:1.2.11.15-43.el6 Dependency Updated: 389-ds-base-libs.x86_64 0:1.2.11.15-43.el6 Complete! [root@rhel6-1 ~]# ipactl restart Restarting Directory Service Shutting down dirsrv: PKI-IPA... [ OK ] TESTRELM-TEST... [ OK ] Starting dirsrv: PKI-IPA... [ OK ] TESTRELM-TEST... [ OK ] Restarting KDC Service Stopping Kerberos 5 KDC: [ OK ] Starting Kerberos 5 KDC: [ OK ] Restarting KPASSWD Service Stopping Kerberos 5 Admin Server: [ OK ] Starting Kerberos 5 Admin Server: [ OK ] Restarting DNS Service Stopping named: [ OK ] Starting named: [ OK ] Restarting MEMCACHE Service Stopping ipa_memcached: [ OK ] Starting ipa_memcached: [ OK ] Restarting HTTP Service Stopping httpd: service s [ OK ] Starting httpd: ssd [ OK ] Restarting CA Service resStopping pki-ca: tart [ OK ] Starting pki-ca: [ OK ] [root@rhel6-1 ~]# service sssd restart Stopping sssd: [ OK ] Starting sssd: [ OK ] [root@rhel6-1 ~]# ssh admin@$(hostname) "hostname; id" admin.test's password: Connection closed by UNKNOWN Expected results: ssh works Additional info: From /var/log/secure: Sep 8 13:07:19 rhel6-1 sshd[3351]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=rhel6-1.testrelm.test user=admin Sep 8 13:07:20 rhel6-1 sshd[3351]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=rhel6-1.testrelm.test user=admin Sep 8 13:07:20 rhel6-1 sshd[3351]: pam_sss(sshd:account): Access denied for user admin: 4 (System error) Sep 8 13:07:20 rhel6-1 sshd[3351]: Failed password for admin from 192.168.122.61 port 60100 ssh2 Sep 8 13:07:20 rhel6-1 sshd[3352]: fatal: Access denied for user admin by PAM account configuration From /var/log/messages: Sep 8 13:07:20 rhel6-1 sssd[be[testrelm.test]]: dereference processing failed : No such file or directory I'll attach dirsrv logs separately.