Re: [Freeipa-devel] #4389: DS deref broken after ACI refactoring
On 06/20/2014 05:51 PM, Jakub Hrozek wrote: On Fri, Jun 20, 2014 at 04:45:45PM +0200, 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: ... I think we should just make a note to self to allow users to fix the ACIs manually should they run into the problem while being unable to upgrade for whatever reason. So we only seem to dereference member and memberof. We dereference either user groups to get users, host groups to get hosts. For hosts we are interested about these attributes: "ipa_host_object_class" "ipa_host_name" "ipa_host_fqdn" "ipa_host_serverhostname" "ipa_host_member_of" "ipa_host_ssh_public_key" "ipa_host_uuid" For users and groups, the list is longer and can be found here: https://git.fedorahosted.org/cgit/sssd.git/tree/src/providers/ipa/ipa_opts.h#n166 Look for ipa_user_map and ipa_group_map. But in general I agree with Simo that we shouldn't spend too much time on this when the DS is fixed. Ok, makes sense. 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... But because the ACIs would only be applied on IPA servers, I think we can limit ourselves to the IPA schema only for the workaround. Thanks all for responses. It seems that plan is clear: 1) Prepare a fix for DS deref access control issue (https://fedorahosted.org/389/ticket/47821). Ludwig, could you now please start working on this one? It takes precedence before 4.1 or 4.2 work you were working on. 2) Backport the fix to supported platforms along with other ACI fixes that Ludwig already found - Fedora 19 (?), Fedora 20, next RHEL-6.x. 3) 4.0 release note will contain a warning about the minimal DS version of the replicas. We will have a workaround ready based on the data that Jakub provided in case someone hit the issue and cannot update to fixes DS version. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4389: DS deref broken after ACI refactoring
On Fri, Jun 20, 2014 at 04:45:45PM +0200, 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. Ah, I didn't realize the bug could propagate to released versions via replicas, sorry. > > >> 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 > >> > >> vYmplY3RDbGFzczGEhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl > >> > >> cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc > >> GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz > >> # managedBy: > >> ;; >> > >> =nshost>;;; >> > >> >;;; >> > >> shhost>;;;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. I think we should just make a note to self to allow users to fix the ACIs manually should they run into the problem while being unable to upgrade for whatever reason. So we only seem to dereference member and memberof. We dereference either user groups to get users, host groups to get hosts. For hosts we are interested about these attributes: "ipa_host_object_class" "ipa_host_name" "ipa_host_fqdn" "ipa_host_serverhostname" "ipa_host_member_of" "ipa_host_ssh_public_key" "ipa_host_uuid" For users and groups, the list is long
Re: [Freeipa-devel] #4389: DS deref broken after ACI refactoring
On Fri, 2014-06-20 at 16:45 +0200, Martin Kosek wrote: > 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. This is the only "issue", and I do not think we can/should jump through many hoops here. The best way IMO, is to fix DS in RHEL6, and make a release note that before migrating to FreeIPA 4.0, you must make sure all replicas have an updated DS version (list versions for all major distros we know about). I do not think we should add any special detection code in 4.0, if the admin fails to update DS on an older replica he has 2 choices: 1. update DS 2. decommission the old replica Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4389: DS deref broken after ACI refactoring
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 vYmplY3RDbGFzczGEhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz # managedBy: ;;;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@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4389: DS deref broken after ACI refactoring
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. >> 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 >> >> vYmplY3RDbGFzczGEhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl >> >> cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc >> GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz >> # managedBy: ;;> =nshost>;;;> >;;;> shhost>;;;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@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4389: DS deref broken after ACI refactoring
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 vYmplY3RDbGFzczGEhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz # managedBy: ;;;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 Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4389: DS deref broken after ACI refactoring
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. > > 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 > vYmplY3RDbGFzczGEhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl > cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc > GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz > # managedBy: ;; =nshost>;;; >;;; shhost>;;;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 > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] #4389: DS deref broken after ACI refactoring
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. 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. 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. 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 vYmplY3RDbGFzczGEhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz # managedBy: ;;;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. The ACIs would be removed when all our supported DS versions have the deref plugin fixed. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel