[Freeipa-devel] [PATCHES] 0532-0533 Extend anonymous read ACI for containers

Martin Kosek mkosek at redhat.com
Fri Apr 18 14:11:25 UTC 2014

On 04/18/2014 04:07 PM, Simo Sorce wrote:
> On Fri, 2014-04-18 at 15:49 +0200, Martin Kosek wrote:
>> On 04/18/2014 03:43 PM, Simo Sorce wrote:
>>> On Fri, 2014-04-18 at 13:50 +0200, Petr Viktorin wrote:
>>>> This extends the "Anonymous read access to containers" ACI to cover 
>>>> cn=etc, as discussed in [0].
>>>> A new objectClass is added so we can exclude virtual ops with 
>>>> targetfilter: ipaVirtualOperation (2.16.840.1.113730.
>>>> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00319.html
>>> LGTM
>> It works perfectly except one subtree we missed during initial review and which
>> we should discuss:
>> cn=replicas,cn=ipa,cn=etc,SUFFIX
>> It contains list of replicas (not FreeIPA masters) connected to FreeIPA.
>> Currently, this only affects Winsync replicas.
>> I just verified that anonymous user can retrieve list of connected ADs via
>> winsync. Question is, how to prevent it given that this is created dynamically
>> also by older FreeIPA server and given that it has no special objectsclass to
>> base a filtration on.
>> Maybe we would need to add a deny ACI in this case after all?
> Or we can add an objectclass here too, the update script will then need
> to look at existing objects dynamically and update them.

This would not work well as older FreeIPA servers would not use this
objectclass when "ipa-replica-manage connect --winsync" is run on them.

> However we could also ass a deny aci only in this subtree for now and
> change it later, if we think that's too much work.
> We have plans to revisit shared replica information storage anyway, so
> perhaps it is not worth spending too much time on this now.
> Simo.

deny ACI is preventing access to nsContainer to anonymous users in
cn=replica... is probably it is our best shot ATM unless we find a better solution.


More information about the Freeipa-devel mailing list