Bug 1112702

Summary: Broken dereference control with the FreeIPA 4.0 ACIs
Product: Red Hat Enterprise Linux 6 Reporter: Martin Kosek <mkosek>
Component: 389-ds-baseAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED ERRATA QA Contact: Sankar Ramalingam <sramling>
Severity: unspecified Docs Contact:
Priority: high    
Version: 6.6CC: dpal, jgalipea, jhrozek, lkrispen, mkosek, nhosoi, nkinder, rcritten, rmeggins, spoore, tlavigne
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.2.11.15-45.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1112698
: 1112824 1140888 (view as bug list) Environment:
Last Closed: 2014-10-14 07:56:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1112698    
Bug Blocks: 990143, 1109379, 1112824    

Description Martin Kosek 2014-06-24 13:56:59 UTC
+++ This bug was initially created as a clone of Bug #1112698 +++

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/4389

I've been triaging a login error issue mkosek had today and I believe the problem is actually on the server side. I'm not sure if it's in IPA (due to the new ACIs maybe) or 389DS.

With the latest F20 IPA + 389DS combination I've been unable to use the OpenLDAP dereference control:
{{{
ldapsearch -Y GSSAPI -h vm-236.idm.lab.eng.brq.redhat.com -b fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com -E 'deref=managedBy:objectClass'
}}}

Normally, what the result should be is a tuple of dereferenced DN and the requested attribute (objectClass in this case). I'm only seeing the DN, though.

What I expect to see in the result is:
{{{
# vm-067.idm.lab.bos.redhat.com, computers, accounts, idm.lab.bos.redhat.com
dn: fqdn=vm-067.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,
 dc=bos,dc=redhat,dc=com
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEeMIQAAAEYBAltYW5hZ2VkQnkEYWZxZ
 G49dm0tMDY3LmlkbS5sYWIuYm9zLnJlZGhhdC5jb20sY249Y29tcHV0ZXJzLGNuPWFjY291bnRzLG
 RjPWlkbSxkYz1sYWIsZGM9Ym9zLGRjPXJlZGhhdCxkYz1jb22ghAAAAKQwhAAAAJ4EC29iamVjdEN
 sYXNzMYQAAACLBAN0b3AECWlwYW9iamVjdAQGbnNob3N0BAdpcGFob3N0BAppcGFzZXJ2aWNlBAdw
 a2l1c2VyBA9rcmJwcmluY2lwYWxhdXgEDGtyYnByaW5jaXBhbAQSa3JidGlja2V0cG9saWN5YXV4B
 AppcGFzc2hob3N0BBRpcGFTc2hHcm91cE9mUHViS2V5cw==
# managedBy: <objectClass=top>;<objectClass=ipaobject>;<objectClass=nshost>;<
 objectClass=ipahost>;<objectClass=ipaservice>;<objectClass=pkiuser>;<objectC
 lass=krbprincipalaux>;<objectClass=krbprincipal>;<objectClass=krbticketpolic
 yaux>;<objectClass=ipasshhost>;<objectClass=ipaSshGroupOfPubKeys>;fqdn=vm-06
 7.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=re
 dhat,dc=com
}}}

That works with ipa-server-3.3.3-28.el7.x86_64 and 389-ds-base-1.3.1.6-25.el7.x86_64.

What I'm seeing with freeipa-server-3.3.90GITfaf8f1e-0.fc20.x86_64 and 389-ds-base-1.3.2.16-1.fc20.x86_64 is
{{{
# vm-086.idm.lab.bos.redhat.com, computers, accounts, idm.lab.eng.brq.redhat.
 com
dn: fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,
 dc=eng,dc=brq,dc=redhat,dc=com
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAB7MIQAAAB1BAltYW5hZ2VkQnkEaGZxZ
 G49dm0tMDg2LmlkbS5sYWIuYm9zLnJlZGhhdC5jb20sY249Y29tcHV0ZXJzLGNuPWFjY291bnRzLG
 RjPWlkbSxkYz1sYWIsZGM9ZW5nLGRjPWJycSxkYz1yZWRoYXQsZGM9Y29t
# managedBy: fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=i
 dm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
}}}

Comment 1 Martin Kosek 2014-06-24 13:59:57 UTC
This bug is a high priority for IPA as without it, users would have an outage  when migrating from RHEL-6 to RHEL-7.1 and still having clients connected to RHEL-6.6 IPA master.

Comment 2 Noriko Hosoi 2014-06-24 16:27:52 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/47825

Comment 3 Noriko Hosoi 2014-06-24 16:32:06 UTC
Hi Martin,

The problem is in RHEL-6.x (389-ds-base-1.2.11.X) or RHEL-7.0 (389-ds-base-1.3.1.X)?

It'd affect the target flag of this bug...
Flags: 	
mkosek: 	rhel-6.6.0 		

Thanks,
--noriko

Comment 4 Noriko Hosoi 2014-06-24 18:22:56 UTC
(In reply to Noriko Hosoi from comment #3)
> Hi Martin,
> 
> The problem is in RHEL-6.x (389-ds-base-1.2.11.X) or RHEL-7.0
> (389-ds-base-1.3.1.X)?
> 
> It'd affect the target flag of this bug...
> Flags: 	
> mkosek: 	rhel-6.6.0 		
> 
> Thanks,
> --noriko

Never mind.  Nathan gave me a clear explanation.  We need to have this fix on all the supported version (1.2.11 and up)  And Ludwig is already working on this issue.

Comment 6 Scott Poore 2014-07-21 19:28:25 UTC
Was this issue found after failure of ssh?

We're discussing where to automate testing for this one.  With ssh tests?  General install tests?  Or, can it cause even more widespread issues? that could affect many different functions other than just login?

Comment 7 Martin Kosek 2014-07-23 14:58:52 UTC
When the issue was occurring, I reproduced it with ssh tests, sudo tests and with the ldapsearch mentioned in the Description. The ldapsearch seems as the most straightforward test to do as "ssh" test is more functional and could be broken by many others things but this particular bug. Also CCing Jakub in case he has other ideas for reproduction.

Comment 8 Jakub Hrozek 2014-07-23 15:02:17 UTC
SSSD uses dereference for fetching group members in one go and for HBAC. So anything that exercises HBAC (any login with a PAM service pretty much) should test the dereference code.

Comment 9 Scott Poore 2014-07-23 21:23:43 UTC
Ok, so sounds like this one affects a lot.

I think I'm missing something though for how to reproduce this.  I tried installing older version of ipa and 389-ds-base:

ipa-server-3.0.0-41.el6.x86_64
389-ds-base-1.2.11.15-36.el6.x86_64

But when I try to lookup the master, I'm seeing expected, not failure (I think):

ldapsearch -Y GSSAPI -h $MASTER  -b "fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test" -E 'deref=managedBy:objectclass'
...
dn: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,
 dc=test
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEOMIQAAAEIBAltYW5hZ2VkQnkEUWZxZ
 G49bWFzdGVyLmlwYTEuZXhhbXBsZS50ZXN0LGNuPWNvbXB1dGVycyxjbj1hY2NvdW50cyxkYz1pcG
 ExLGRjPWV4YW1wbGUsZGM9dGVzdKCEAAAApDCEAAAAngQLb2JqZWN0Y2xhc3MxhAAAAIsEA3RvcAQ
 JaXBhb2JqZWN0BAZuc2hvc3QEB2lwYWhvc3QECmlwYXNlcnZpY2UEB3BraXVzZXIED2tyYnByaW5j
 aXBhbGF1eAQMa3JicHJpbmNpcGFsBBJrcmJ0aWNrZXRwb2xpY3lhdXgECmlwYXNzaGhvc3QEFGlwY
 VNzaEdyb3VwT2ZQdWJLZXlz
# managedBy: <objectclass=top>;<objectclass=ipaobject>;<objectclass=nshost>;<
 objectclass=ipahost>;<objectclass=ipaservice>;<objectclass=pkiuser>;<objectc
 lass=krbprincipalaux>;<objectclass=krbprincipal>;<objectclass=krbticketpolic
 yaux>;<objectclass=ipasshhost>;<objectclass=ipaSshGroupOfPubKeys>;fqdn=maste
 r.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test

I even tried installing a separate client in case this didn't affect master:

dn: fqdn=client1.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example
 ,dc=test
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEKMIQAAAEEBAltYW5hZ2VkQnkEUmZxZ
 G49Y2xpZW50MS5pcGExLmV4YW1wbGUudGVzdCxjbj1jb21wdXRlcnMsY249YWNjb3VudHMsZGM9aX
 BhMSxkYz1leGFtcGxlLGRjPXRlc3SghAAAAJ8whAAAAJkEC29iamVjdGNsYXNzMYQAAACGBAlpcGF
 vYmplY3QEBm5zaG9zdAQHaXBhaG9zdAQHcGtpdXNlcgQKaXBhc2VydmljZQQPa3JicHJpbmNpcGFs
 YXV4BAxrcmJwcmluY2lwYWwEDWllZWU4MDJkZXZpY2UECmlwYXNzaGhvc3QEA3RvcAQUaXBhU3NoR
 3JvdXBPZlB1YktleXM=
# managedBy: <objectclass=ipaobject>;<objectclass=nshost>;<objectclass=ipahos
 t>;<objectclass=pkiuser>;<objectclass=ipaservice>;<objectclass=krbprincipala
 ux>;<objectclass=krbprincipal>;<objectclass=ieee802device>;<objectclass=ipas
 shhost>;<objectclass=top>;<objectclass=ipaSshGroupOfPubKeys>;fqdn=client1.ip
 a1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test

Is there something else I need to do in order for the ldapsearch to show the failure?

Comment 10 Ludwig 2014-07-24 07:00:37 UTC
the problem became only visible in recent version of IPA where new acis were introduced.
The problem is triggered if access to the managedby attribute is granted by an aci containing a targetfilter rule

Comment 11 Scott Poore 2014-07-24 13:55:12 UTC
How can I confirm those acis are or aren't in place?  And, can I manually add one to test with?

Comment 12 Scott Poore 2014-07-24 18:13:17 UTC
Should I be able to add the aci with ipa permission-add command?  Do we have an example I could use for that?

Thanks,
Scott

Comment 13 Martin Kosek 2014-07-25 07:48:33 UTC
No, this depends on a permission/ACI refactoring done in FreeIPA 4.0 (http://www.freeipa.org/page/V4/Permissions_V2). I think the easiest way is to:

1) Install RHEL-6.6 IPA server
2) Install FreeIPA 4.0 replica (http://www.freeipa.org/page/Releases/4.0.0)
3) Test that the deref LDAP works or do functional tests as advised in Comment 7 and Comment 8

Alternatively, you could verify this as sanity only and only verify that current deref LDAP searches are not broken.

Comment 14 Scott Poore 2014-07-25 15:20:31 UTC
Ok, great.  I've been able to reproduce with RHEL 6.5 master and Fedora 20 replica running freeipa 4.0.1.

With 389-ds-base-1.2.11.15-29.el6.x86_64:

[root@rhel6-1 ~]# ldapsearch -Y GSSAPI -h $MASTER  -b "fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test" -E 'deref=managedBy:objectclass'
SASL/GSSAPI authentication started
SASL username: host/master.ipa1.example.test@IPA1.EXAMPLE.TEST
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
# with dereference control
#

# master.ipa1.example.test, computers, accounts, ipa1.example.test
dn: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,
 dc=test
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAABkMIQAAABeBAltYW5hZ2VkQnkEUWZxZ
 G49bWFzdGVyLmlwYTEuZXhhbXBsZS50ZXN0LGNuPWNvbXB1dGVycyxjbj1hY2NvdW50cyxkYz1pcG
 ExLGRjPWV4YW1wbGUsZGM9dGVzdA==
# managedBy: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,d
 c=example,dc=test

So, I'll update and verify. 

Thanks for the help here.

Comment 15 Scott Poore 2014-07-25 15:22:49 UTC
Verified.

Version ::

389-ds-base-1.2.11.15-38.el6.x86_64

Results ::

[root@rhel6-1 ~]# yum update 389-ds-base
Loaded plugins: product-id, security, 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-29.el6 will be updated
---> Package 389-ds-base.x86_64 0:1.2.11.15-38.el6 will be an update
--> Processing Dependency: 389-ds-base-libs = 1.2.11.15-38.el6 for package: 389-ds-base-1.2.11.15-38.el6.x86_64
--> Running transaction check
---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-29.el6 will be updated
---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-38.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-38.el6        beaker-rhel-6.6-latest-server       1.5 M
Updating for dependencies:
 389-ds-base-libs       x86_64       1.2.11.15-38.el6        beaker-rhel-6.6-latest-server       414 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-38.el6.x86_64.rpm                                  | 1.5 MB     00:01     
(2/2): 389-ds-base-libs-1.2.11.15-38.el6.x86_64.rpm                             | 414 kB     00:00     
-------------------------------------------------------------------------------------------------------
Total                                                                  545 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-38.el6.x86_64                                            1/4 
  Updating   : 389-ds-base-1.2.11.15-38.el6.x86_64                                                 2/4 
  Cleanup    : 389-ds-base-1.2.11.15-29.el6.x86_64                                                 3/4 
  Cleanup    : 389-ds-base-libs-1.2.11.15-29.el6.x86_64                                            4/4 
beaker-rhel-6.6-latest-server/productid                                         | 1.6 kB     00:00     
beaker-rhel65-server/productid                                                  | 1.7 kB     00:00     
  Verifying  : 389-ds-base-libs-1.2.11.15-38.el6.x86_64                                            1/4 
  Verifying  : 389-ds-base-1.2.11.15-38.el6.x86_64                                                 2/4 
  Verifying  : 389-ds-base-1.2.11.15-29.el6.x86_64                                                 3/4 
  Verifying  : 389-ds-base-libs-1.2.11.15-29.el6.x86_64                                            4/4 

Updated:
  389-ds-base.x86_64 0:1.2.11.15-38.el6                                                                

Dependency Updated:
  389-ds-base-libs.x86_64 0:1.2.11.15-38.el6                                                           

Complete!
[root@rhel6-1 ~]# ipactl restart
Restarting Directory Service
Shutting down dirsrv: 
    IPA1-EXAMPLE-TEST...                                   [  OK  ]
    PKI-IPA...                                             [  OK  ]
Starting dirsrv: 
    IPA1-EXAMPLE-TEST...                                   [  OK  ]
    PKI-IPA...                                             [  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:                                            [  OK  ]
Starting httpd:                                            [  OK  ]
Restarting CA Service
Stopping pki-ca:                                           [  OK  ]
Starting pki-ca:                                           [  OK  ]
[root@rhel6-1 ~]# ldapsearch -Y GSSAPI -h $MASTER  -b "fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test" -E 'deref=managedBy:objectclass'
SASL/GSSAPI authentication started
SASL username: host/master.ipa1.example.test@IPA1.EXAMPLE.TEST
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
# with dereference control
#

# master.ipa1.example.test, computers, accounts, ipa1.example.test
dn: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,
 dc=test
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEOMIQAAAEIBAltYW5hZ2VkQnkEUWZxZ
 G49bWFzdGVyLmlwYTEuZXhhbXBsZS50ZXN0LGNuPWNvbXB1dGVycyxjbj1hY2NvdW50cyxkYz1pcG
 ExLGRjPWV4YW1wbGUsZGM9dGVzdKCEAAAApDCEAAAAngQLb2JqZWN0Y2xhc3MxhAAAAIsEA3RvcAQ
 JaXBhb2JqZWN0BAZuc2hvc3QEB2lwYWhvc3QECmlwYXNlcnZpY2UEB3BraXVzZXIED2tyYnByaW5j
 aXBhbGF1eAQMa3JicHJpbmNpcGFsBBJrcmJ0aWNrZXRwb2xpY3lhdXgECmlwYXNzaGhvc3QEFGlwY
 VNzaEdyb3VwT2ZQdWJLZXlz
# managedBy: <objectclass=top>;<objectclass=ipaobject>;<objectclass=nshost>;<
 objectclass=ipahost>;<objectclass=ipaservice>;<objectclass=pkiuser>;<objectc
 lass=krbprincipalaux>;<objectclass=krbprincipal>;<objectclass=krbticketpolic
 yaux>;<objectclass=ipasshhost>;<objectclass=ipaSshGroupOfPubKeys>;fqdn=maste
 r.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test

Comment 20 Martin Kosek 2014-09-05 12:50:51 UTC
Unfortunately, SSSD team discovered that current deref fixes are not sufficient and SSSD will fail to enumerate groups with users having a special IPA RBAC role assigned.

The root cause of the issue is that user contains some memberOf attributes to entries which are not visible to SSSD and DS returns incomplete results in the deref call. This problem makes SSSD to fail in resolving such user groups.

We plan to solve this issue both on server side - in 389-ds-base component, i.e. this bug. Upstream tracks the problem in ticket
https://fedorahosted.org/389/ticket/47885
This should be done for RHEL-6.6 as it is already a minimal IPA server version to use when RHEL-7.1 replica is being added due to this Bugzilla.

Second part is a fix on SSSD client to be more robust in the deref call and fall back properly - tracked in Bug 1135432 targeted on later RHEL release.

Moving this bug back to ASSIGNED so that we can add the additional fix so that RHEL clients can work with RHEL-6.6 servers replicating with RHEL-7.1 servers.

Comment 23 Sankar Ramalingam 2014-09-08 09:46:36 UTC
Looks like newer build has come for 389-ds-base. I am not sure whether the same can be verified by DS QE team... Can this fix be verified by SSSD team?

Comment 24 Noriko Hosoi 2014-09-08 16:20:06 UTC
(In reply to Sankar Ramalingam from comment #23)
> Looks like newer build has come for 389-ds-base. I am not sure whether the
> same can be verified by DS QE team... Can this fix be verified by SSSD team?

This fix for the ticket 47885 can be verified just on the directory server.

Ludwig, could you please put the steps to verify?  Thanks!!

Comment 25 Ludwig 2014-09-09 07:19:01 UTC
steps to verify

0. enabel deref and memberof plugin (use member as memberof attr)
1. create a suffix dc=example,dc=com
2. remove all acis
3, create a public and privaet subtree:

dn: ou=public,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: public
aci: (targetattr!="userPassword")(version 3.0; acl "Anonymous access"; allow (read,search,compare) userdn="ldap:///anyone";)

dn: ou=private,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: private

4. add a public and private group

dn: cn=g1,ou=private,dc=example,dc=com
objectClass: groupofnames
objectClass: top
member: uid=user.9999,ou=People,dc=example,dc=com
cn: g1

dn: cn=g1,ou=public,dc=example,dc=com
member: uid=user.9999,ou=People,dc=example,dc=com
objectClass: groupofnames
objectClass: top
cn: g1

5. do search with deref control as dirctory manager, you will get both groups:
ldapsearch .....-D "cn=directory manager" -w  ... -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" memberof

dn: uid=user.9999,ou=People,dc=example,dc=com
# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=private,dc=example,dc=com

# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=example,dc=com

memberof: cn=g1,ou=private,dc=example,dc=com
memberof: cn=g1,ou=public,dc=example,dc=com


6. do the same search as an ordinary user, it should only deref the public group:

ldapsearch -LLL -o ldif-wrap=no -x -h localhost -p 30522 -D "uid=user.9998,ou=People,dc=example,dc=com" -w password -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" memberof

dn: uid=user.9999,ou=People,dc=example,dc=com
# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=example,dc=com

memberof: cn=g1,ou=private,dc=example,dc=com
memberof: cn=g1,ou=public,dc=example,dc=com

Comment 26 Sankar Ramalingam 2014-09-10 13:25:53 UTC
Created ou, groups and users as given in comment #25. But, there are few modifications to be done to get the exact result.

Step 0: use memberof as memberof attr in memberOf plug-in. Not member as memberof attr.


Before doing step4, you need to create user.9999

dn: uid=user.9999,ou=public,dc=example3,dc=com
telephoneNumber: 989898199
mail: user.9999@redhat.com
uid: user.9999
givenName: user.9999
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetUser
sn: user.9999
cn: user.9999
userPassword: Secret123

Step 4: use public instead of people for member attr in private and public groups.

dn: cn=g1,ou=private,dc=example,dc=com
objectClass: groupofnames
objectClass: top
member: uid=user.9999,ou=public,dc=example,dc=com
cn: g1

dn: cn=g1,ou=public,dc=example,dc=com
member: uid=user.9999,ou=public,dc=example,dc=com
objectClass: groupofnames
objectClass: top
cn: g1

Step 5: ldapsearch -x -p 1289 -h localhost -D "cn=Directory Manager" -w Secret123 -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" "# memberof:"

Result:
# user.9999, public, example.com
dn: uid=user.9999,ou=public,dc=example,dc=com
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAADNMIQAAABhBAhtZW1iZXJvZgQjY249Z
 zEsb3U9cHJpdmF0ZSxkYz1leGFtcGxlMyxkYz1jb22ghAAAACwwhAAAACYEC29iamVjdGNsYXNzMY
 QAAAATBAxncm91cG9mbmFtZXMEA3RvcDCEAAAAYAQIbWVtYmVyb2YEImNuPWcxLG91PXB1YmxpYyx
 kYz1leGFtcGxlMyxkYz1jb22ghAAAACwwhAAAACYEC29iamVjdGNsYXNzMYQAAAATBAxncm91cG9m
 bmFtZXMEA3RvcA==
# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=private,dc=
 example,dc=com

# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=e
 xample,dc=com


Step 6: Add user.9993 to ou=public as user.9999.

Run ldapsearch as user.9993
ldapsearch -x -p 1289 -h localhost -D "uid=user.9993,ou=public,dc=example,dc=com" -w Secret123 -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" "deref=memberof:objectclass" "# memberof:"

Result:
# user.9999, public, example.com
dn: uid=user.9999,ou=public,dc=example,dc=com
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAABmMIQAAABgBAhtZW1iZXJvZgQiY249Z
 zEsb3U9cHVibGljLGRjPWV4YW1wbGUzLGRjPWNvbaCEAAAALDCEAAAAJgQLb2JqZWN0Y2xhc3MxhA
 AAABMEDGdyb3Vwb2ZuYW1lcwQDdG9w
# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=e
 xample,dc=com


Ldapsearch as normal user with deref control produces results only with public groups. Hence, marking the bug as verified.

Comment 27 Sankar Ramalingam 2014-09-10 18:03:30 UTC
can I know the reason why it has been changed to POST? Is there anything changing from what I posted in the verification steps?

Comment 28 Noriko Hosoi 2014-09-10 18:17:00 UTC
(In reply to Sankar Ramalingam from comment #27)
> can I know the reason why it has been changed to POST? Is there anything
> changing from what I posted in the verification steps?

Because of a regression by the ticket 47885, another build is coming including the fix.

This final verification can be done by IPA, I think.

Comment 29 Noriko Hosoi 2014-09-10 18:20:44 UTC
Please see also https://bugzilla.redhat.com/show_bug.cgi?id=1139361
Bug 1139361 - RHEL6.6 ssh as admin on ipa server fails after 389-ds-base update

Comment 30 Nathan Kinder 2014-09-11 18:42:54 UTC
Reopening due to regressions encountered (described in bug 1139361).

Comment 31 Nathan Kinder 2014-09-11 18:43:16 UTC
*** Bug 1139361 has been marked as a duplicate of this bug. ***

Comment 32 Scott Poore 2014-09-11 20:24:16 UTC
This version seems to fix my issue from bug #1139361 for ssh as admin:

[root@rhel6-1 ~]# rpm -q 389-ds-base
389-ds-base-1.2.11.15-43.el6.x86_64
[root@rhel6-1 ~]# ssh admin@$(hostname)
admin@rhel6-1.testrelm.test's password: 
Connection closed by UNKNOWN

After upgade to release -45, it works:

[root@rhel6-1 yum.local.d]# 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
mylocal                                                                         | 2.9 kB     00:00 ... 
mylocal/primary_db                                                              |  36 kB     00:00 ... 
Resolving Dependencies
--> Running transaction check
---> Package 389-ds-base.x86_64 0:1.2.11.15-44.el6 will be updated
---> Package 389-ds-base.x86_64 0:1.2.11.15-45.el6 will be an update
--> Processing Dependency: 389-ds-base-libs = 1.2.11.15-45.el6 for package: 389-ds-base-1.2.11.15-45.el6.x86_64
--> Running transaction check
---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-44.el6 will be updated
---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-45.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-45.el6               mylocal            1.5 M
Updating for dependencies:
 389-ds-base-libs            x86_64            1.2.11.15-45.el6               mylocal            417 k

Transaction Summary
=======================================================================================================
Upgrade       2 Package(s)

Total download size: 1.9 M
Is this ok [y/N]: y
Downloading Packages:
-------------------------------------------------------------------------------------------------------
Total                                                                  102 MB/s | 1.9 MB     00:00     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : 389-ds-base-libs-1.2.11.15-45.el6.x86_64                                            1/4 
  Updating   : 389-ds-base-1.2.11.15-45.el6.x86_64                                                 2/4 
  Cleanup    : 389-ds-base-1.2.11.15-44.el6.x86_64                                                 3/4 
  Cleanup    : 389-ds-base-libs-1.2.11.15-44.el6.x86_64                                            4/4 
  Verifying  : 389-ds-base-1.2.11.15-45.el6.x86_64                                                 1/4 
  Verifying  : 389-ds-base-libs-1.2.11.15-45.el6.x86_64                                            2/4 
  Verifying  : 389-ds-base-libs-1.2.11.15-44.el6.x86_64                                            3/4 
  Verifying  : 389-ds-base-1.2.11.15-44.el6.x86_64                                                 4/4 

Updated:
  389-ds-base.x86_64 0:1.2.11.15-45.el6                                                                

Dependency Updated:
  389-ds-base-libs.x86_64 0:1.2.11.15-45.el6                                                           

Complete!

[root@rhel6-1 yum.local.d]# 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:                                            [  OK  ]
Starting httpd:                                            [  OK  ]
Restarting CA Service
Stopping pki-ca:                                           [  OK  ]
Starting pki-ca:                                           [  OK  ]

[root@rhel6-1 yum.local.d]# ssh admin@$(hostname)
admin@rhel6-1.testrelm.test's password: 
Last login: Tue Sep  9 08:10:00 2014 from rhel6-1.testrelm.test
Could not chdir to home directory /home/admin: No such file or directory

-bash-4.1$ exit
logout

I'm still running other tests but, that issue does seem to be resolved.

Thank you!

Comment 33 Sankar Ramalingam 2014-09-15 17:44:35 UTC
Changing the status to ON_QA as per Noriko's comment #30.

Comment 34 Sankar Ramalingam 2014-09-16 21:05:55 UTC
Based on comment #32, marking the bug as Verified. Thanks Scott!

Comment 35 errata-xmlrpc 2014-10-14 07:56:19 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1385.html