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.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1112698
DS bug: https://bugzilla.redhat.com/show_bug.cgi?id=1112702
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.
Promising DS fixed build is in updates-testing now: https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.19-1.fc20
My results obtained with 389-ds-base-1.3.2.19-1.fc20 indicate that it works now:
389-ds-base-1.3.2.19-1.fc20
# 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.
389-ds-base-devel-1.3.2.16-1.fc20.x86_64
master:
Metadata Update from @jhrozek: - Issue assigned to lkrispen - Issue set to the milestone: FreeIPA 4.0 GA
Login to comment on this ticket.