#4389 Broken dereference control with the FreeIPA 4.0 ACIs
Closed: Fixed None Opened 4 years ago by jhrozek.

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

I think it is an aci issue. i did the following test:

There are two acis:

aci: (targetattr ="member || objectclass")(version 3.0;acl "Allow deref";allow (read,search,compare)(userdn = "ldap:///uid=user.7720,ou=People,dc=example,dc=com");)
aci: (targetattr ="member || cn")(version 3.0;acl "Allow deref 2";allow (read,search,compare)(userdn = "ldap:///uid=user.7721,ou=People,dc=example,dc=com");)

I do a search as user7720: .... E '!deref=member:uid,objectclass' 'objectclass=groupofnames'
and get:

# member: <objectclass=top>;<objectclass=person>;<objectclass=organizationalPerson>;<objectclass=inetOrgPerson>;uid=user.7724,ou=People,dc=example,dc=com

only the objectclass attr is dereference, not uid

as user7721:_ ...-E '!deref=member:uid,objectclass' 'cn=group_sub_B'
I get

# member: uid=user.7724,ou=People,dc=example,dc=com

so only the attributes which can be accessed are returned for the deref entry

Would you have any advise what should we fix in FreeIPA ACIs then? objectclass attribute is accessible to regular users, so it should work:

# kinit -kt /etc/krb5.keytab
# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_yhQ6fT5
Default principal: host/vm-236.idm.lab.eng.brq.redhat.com@IDM.LAB.ENG.BRQ.REDHAT.COM

Valid starting       Expires              Service principal
06/20/2014 13:25:11  06/21/2014 13:25:11  krbtgt/IDM.LAB.ENG.BRQ.REDHAT.COM@IDM.LAB.ENG.BRQ.REDHAT.COM

# ipa host-show `hostname` --all --raw
  dn: fqdn=vm-236.idm.lab.eng.brq.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
  fqdn: vm-236.idm.lab.eng.brq.redhat.com
...
  managedby: fqdn=vm-236.idm.lab.eng.brq.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
...
  objectClass: ipaobject
  objectClass: krbprincipal
  objectClass: nshost
  objectClass: top
  objectClass: ipaservice
  objectClass: pkiuser
  objectClass: ipahost
  objectClass: krbticketpolicyaux
  objectClass: krbprincipalaux
  objectClass: ipasshhost
  objectClass: ipaSshGroupOfPubKeys
...

Me and Ludwig found more details about this issue, I started a related discussion on freeipa-devel.

This is an issue in the DS, we will only bump the Requires in spec file in FreeIPA.

Adding to list of tickets required for 4.0 release.

DS part of the ticket is solved by Ludwig. When this is done, we would just bump our Requires in the spec.

My results obtained with 389-ds-base-1.3.2.19-1.fc20 indicate that it works now:

# ldapsearch -Y GSSAPI -b fqdn=vm-152.idm.lab.eng.brq.redhat.com,cn=computers,cn=accounts,dc=ipa,dc=example -E 'deref=managedBy:objectClass'
SASL/GSSAPI authentication started
SASL username: tester@IPA.EXAMPLE
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <fqdn=vm-152.idm.lab.eng.brq.redhat.com,cn=computers,cn=accounts,dc=ipa,dc=example> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
# with dereference control
#

# vm-152.idm.lab.eng.brq.redhat.com, computers, accounts, ipa.example
dn: fqdn=vm-152.idm.lab.eng.brq.redhat.com,cn=computers,cn=accounts,dc=ipa,dc=
 example
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEOMIQAAAEIBAltYW5hZ2VkQnkEUWZxZ
 G49dm0tMTUyLmlkbS5sYWIuZW5nLmJycS5yZWRoYXQuY29tLGNuPWNvbXB1dGVycyxjbj1hY2NvdW
 50cyxkYz1pcGEsZGM9ZXhhbXBsZaCEAAAApDCEAAAAngQLb2JqZWN0Q2xhc3MxhAAAAIsEA3RvcAQ
 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=vm-15
 2.idm.lab.eng.brq.redhat.com,cn=computers,cn=accounts,dc=ipa,dc=example

cn: vm-152.idm.lab.eng.brq.redhat.com
objectClass: top
objectClass: ipaobject
objectClass: nshost
objectClass: ipahost
objectClass: ipaservice
objectClass: pkiuser
objectClass: krbprincipalaux
objectClass: krbprincipal
objectClass: krbticketpolicyaux
objectClass: ipasshhost
objectClass: ipaSshGroupOfPubKeys
krbLastPwdChange: 20140702123948Z
fqdn: vm-152.idm.lab.eng.brq.redhat.com
managedBy: fqdn=vm-152.idm.lab.eng.brq.redhat.com,cn=computers,cn=accounts,dc=
 ipa,dc=example
krbPrincipalName: host/vm-152.idm.lab.eng.brq.redhat.com@IPA.EXAMPLE
serverHostName: vm-152
ipaUniqueID: f46a2c34-01e5-11e4-ae3f-001a4a22219d
ipaSshPubKey: ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAy
 NTYAAABBBFv0Ns6VLOG6bpK4MYRscNSkzik2BudR5YcRh7y03zerJBAMTt/H4PnHbu3CvnodA+Fz8
 BGrl1Kf+NN/DCKOBP4=
ipaSshPubKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDuKeMDcVmFMsDdLVyBnISMetfc
 zsN+kID4t3MrsigoP5/SVctg5gsIAy0FThjHo6D77xP0phlg3JgRRrZa8fSJT58KEd1R+ea81j+ev
 0BIaOQMnJIlshJKmPqXp6lCUzbE7XLOBb0WcCgbW3sEBEYv0Ez/Yz6Eq5820ayyL6egyG6H477kQc
 hSSnMIHARGXz6HIhSYkADcBa9pyE7M3qu/urp54AP/Y9o/gYjfTmnPAUet24uroOhfClpv6CzpX6U
 BLEuOBU75UC70gtzhczFr+icqVIeVCRk+GrfvKCuPw/JBOTn0WhqLd2sca43ljYDOV/3Omz3sLNDU
 YcwOJHUP

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1

I have tested it on clean installation and also on upgrade from 389-ds-base-devel-1.3.2.16-1.fc20.x86_64.

master:

  • 5434851 Prepare spec for 4.0 release

Metadata Update from @jhrozek:
- Issue assigned to lkrispen
- Issue set to the milestone: FreeIPA 4.0 GA

2 years ago

Login to comment on this ticket.

Metadata