On 06/20/2014 04:24 PM, Jakub Hrozek wrote:
On Fri, Jun 20, 2014 at 04:06:16PM +0200, Martin Kosek wrote:
Hello all,
I would like to discuss what should we do with the latest issue we found in
SSSD-DS communication which is broken after the ACI refactoring.
It's not just SSSD-DS communication, any client, including ldapsearch
currently fails.
I was working with Ludwig, there is a problem in the way how deref plugin
checks the access to the referenced entry. Instead of checking the target entry
itself, Ludwig found out that the deref plugin checks a dummy entry created
from the dereferenced DN, not the real entry. Details in DS ticket:
https://fedorahosted.org/389/ticket/47821
Previously, we allowed read access globally so it worked fine. Now, when we
have targeted ACIs using objectclass targetfilter, the access control goes
wrong, deref plugin does not return all attributes and SSSD does not work (see
4389).
Question is, what should we do in 4.0. We could have the DS team to fix the
deref plugin, but this would break SSSD connected to old RHEL/CentOs 6.x
replicas which would not have the fix. So we need to be cautious about this one.
Why? SSSD Simply uses a client control. See
http://tools.ietf.org/html/draft-masarati-ldap-deref-00 for all the
details.
I see couple ways:
1) Fix DS deref plugin in F20 and next RHEL 6.x and specify the RHEL-6.x as
minimal version of FreeIPA/DS required when replicating with FreeIPA 4.0. This
option is a bit clumsy.
The fact that this 'fix' seems to be backwards incompatible sounds
strange to me. How exactly did you intend to fix the plugin? If the fix
was about changing DS to check the target entry instead of some dummy
entry, then I see no impact on the client.
The DS fix will be in checking the target entry, but martins concern
seem to be that this fix will not be automatically present in all
deployments
2) Add temporary ACIs allowing access to attributes that SSSD needs for deref
calls. I tested it with Jakub's example call and it fixed this query:
# ipa permission-add --subtree
cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
--right={read,search,compare} --attrs={objectclass,memberof,managedby}
--bindtype all deref_managedby
# kinit -kt /etc/krb5.keytab
# 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'
...
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 MIQAAAEgMIQAAAEaBAltYW5hZ2VkQnkEaGZxZ
G49dm0tMDg2LmlkbS5sYWIuYm9zLnJlZGhhdC5jb20sY249Y29tcHV0ZXJzLGNuPWFjY291bnRzLG
RjPWlkbSxkYz1sYWIsZGM9ZW5nLGRjPWJycSxkYz1yZWRoYXQsZGM9Y29toIQAAACfMIQAAACZBAt
vYmplY3RDbGFzczGEAAAAhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl
cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc
GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz
# managedBy: <objectClass=ipaobject>;<objectClass=ieee802device>;<objectClass
=nshost>;<objectClass=ipaservice>;<objectClass=pkiuser>;<objectClass=ipahost
>;<objectClass=krbprincipal>;<objectClass=krbprincipalaux>;<objectClass=ipas
shhost>;<objectClass=top>;<objectClass=ipaSshGroupOfPubKeys>;fqdn=vm-086.idm
.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=
redhat,dc=com
Jakub, what else would we need to allow? After this change, login/sudo seemed
to work for me on F20.
Are you asking about the list of attributes we dereference or the list
of attributes we read from the dereferenced entries?
For IPA we only care about memberof, but keep in mind that attribute
maps in SSSD are configurable.
The ACIs would be removed when all our supported DS versions have the deref
plugin fixed.
--
Martin Kosek <[email protected]>
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
