[Freeipa-devel] #4389: DS deref broken after ACI refactoring

[Ludwig Krispenz]

On 06/20/2014 04:45 PM, Martin Kosek wrote:
> 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.
> Sure.
>
>>> 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.
> Because this bug affects all client machines enrolled in FreeIPA.
>
>>> 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.
> There is no impact on clients connected to the "fixed DS". This is the scenario
> I am concerned about:
>
> User has RHEL/CentOS 6.x IPA server and wants to try the new nice and shiny
> FreeIPA 4.0. He installs the FreeIPA 4.0 replica (with fixed DS), the replica
> upgrades the ACIs to the new model. SSSD connected to FreeIPA 4.0 replica will
> work, SSSD connected to the old RHEL-6.x replica will not.
About the options, I think 1] is mandatory: fix DS
and then, in a mixed environment, we could either request to either 
upgrade DS to a version including the fix or to add an aci the way you did.
>
>>> 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?
> Actually both, so that we know for what type of objects and what attributes we
> would need to allow access.
>
>> For IPA we only care about memberof, but keep in mind that attribute
>> maps in SSSD are configurable.
> Hm, makes the option 2) even more challenging...
>
> Martin
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel