Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/13/2014 07:23 PM, Nathaniel McCallum wrote: On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: On 10/10/2014 05:43 PM, Nathaniel McCallum wrote: As a result of this ongoing conversation, I have opened two 389 bugs: 1. Post Read - https://fedorahosted.org/389/ticket/47924 2. UUID ACIs - https://fedorahosted.org/389/ticket/47925 On Wed, 2014-10-08 at 17:46 -0400, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. Given the number of issues we have with this patch on the DS side, it is likely we will need to go some simpler way for FreeIPA 4.1, in terms just of hiding the option where appropriate. We have solved the first DS issue via a sensible workaround. Attached are two new patches. These take into account your feedback below and incorporate the aforementioned workaround. The only thing these patches lack is the tightening of the ACI (problem #2 in the first email). Merging these patches I believe provides benefits over our current code, even though we don't get the final benefit of forcing normal users to use autogeneration. If we test/merge these now, then when the second DS problem is solved, we can simply update the ACI independently via a trivial second patch (s/\*/autogenerate/). Ok. We can merge the patches if they at least improve the situation and prepare us for the future. Also, few comments to your current patch set (though the patches themselves will probably not land in 4.1): Patch 0001: - while it may work (after DS fixes), it adds PostRead for all our commands, not just otptoken-add. I would rather have some attribute like read_dn_from_postread on LDAPObject which defaults to False to make sure there is no regression or performance hit with other LDAP calls. In the new code, we actually get a performance gain as the manual post read is eliminated if the post read control is successful. Only one issue can arise, which is when the post read control evaluates ACIs in a different context than a normal manual read. This problem is well known and is trivial to fix (s/USERDN/SELFDN/). That's my point - with such a big change, we can hit many unforeseen issues and we are close to deadline. I would rather like to use the PostRead control only in otptoken_add command. CCing Petr and Honza to chime in. - Wider adoption of the PostRead call would be left for future, when we stop doing post-execute LDAP read call and only rely on PostRead result. This is already integrated. Patch 0002: - cn=IPA Token Unique IDs,cn=IPA UUID,cn=plugins,cn=config should be created in LDAP update files only. Currently it will not be created on upgrades. Fixed. I would recommend testing your patches before you send them. Just based on reading the
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
Dne 14.10.2014 v 08:37 Martin Kosek napsal(a): On 10/13/2014 07:23 PM, Nathaniel McCallum wrote: On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: Also, few comments to your current patch set (though the patches themselves will probably not land in 4.1): Patch 0001: - while it may work (after DS fixes), it adds PostRead for all our commands, not just otptoken-add. I would rather have some attribute like read_dn_from_postread on LDAPObject which defaults to False to make sure there is no regression or performance hit with other LDAP calls. In the new code, we actually get a performance gain as the manual post read is eliminated if the post read control is successful. Only one issue can arise, which is when the post read control evaluates ACIs in a different context than a normal manual read. This problem is well known and is trivial to fix (s/USERDN/SELFDN/). That's my point - with such a big change, we can hit many unforeseen issues and we are close to deadline. I would rather like to use the PostRead control only in otptoken_add command. CCing Petr and Honza to chime in. I agree it should be opt-in for now. Add a boolean argument to add_entry as a switch. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/14/2014 08:51 AM, Jan Cholasta wrote: Dne 14.10.2014 v 08:37 Martin Kosek napsal(a): On 10/13/2014 07:23 PM, Nathaniel McCallum wrote: On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: Also, few comments to your current patch set (though the patches themselves will probably not land in 4.1): Patch 0001: - while it may work (after DS fixes), it adds PostRead for all our commands, not just otptoken-add. I would rather have some attribute like read_dn_from_postread on LDAPObject which defaults to False to make sure there is no regression or performance hit with other LDAP calls. As Honza says later in the mail, this should be an argument for add_entry (or alternatively an additional add_entry_with_postread method). Storing settings in data objects leads to trouble – when you get such an object from somewhere, you never know what an operation on it will do. In the new code, we actually get a performance gain as the manual post read is eliminated if the post read control is successful. Only one issue can arise, which is when the post read control evaluates ACIs in a different context than a normal manual read. This problem is well known and is trivial to fix (s/USERDN/SELFDN/). That's my point - with such a big change, we can hit many unforeseen issues and we are close to deadline. I would rather like to use the PostRead control only in otptoken_add command. CCing Petr and Honza to chime in. I agree it should be opt-in for now. Add a boolean argument to add_entry as a switch. +1 Also, I think the add_entry should not return anything; rather the PostRead result should be merged into the added entry object. Honza, what do you think? In the future it might be useful for add_entry to return a list of controls, the `ctrls` in this patch. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
Dne 14.10.2014 v 10:23 Petr Viktorin napsal(a): On 10/14/2014 08:51 AM, Jan Cholasta wrote: Dne 14.10.2014 v 08:37 Martin Kosek napsal(a): On 10/13/2014 07:23 PM, Nathaniel McCallum wrote: On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: Also, few comments to your current patch set (though the patches themselves will probably not land in 4.1): Patch 0001: - while it may work (after DS fixes), it adds PostRead for all our commands, not just otptoken-add. I would rather have some attribute like read_dn_from_postread on LDAPObject which defaults to False to make sure there is no regression or performance hit with other LDAP calls. As Honza says later in the mail, this should be an argument for add_entry (or alternatively an additional add_entry_with_postread method). Storing settings in data objects leads to trouble – when you get such an object from somewhere, you never know what an operation on it will do. I would prefer add_entry argument rather than a new method, as that's how find_entries does controls. In the new code, we actually get a performance gain as the manual post read is eliminated if the post read control is successful. Only one issue can arise, which is when the post read control evaluates ACIs in a different context than a normal manual read. This problem is well known and is trivial to fix (s/USERDN/SELFDN/). That's my point - with such a big change, we can hit many unforeseen issues and we are close to deadline. I would rather like to use the PostRead control only in otptoken_add command. CCing Petr and Honza to chime in. I agree it should be opt-in for now. Add a boolean argument to add_entry as a switch. +1 Also, I think the add_entry should not return anything; rather the PostRead result should be merged into the added entry object. Honza, what do you think? It should, good point. In the future it might be useful for add_entry to return a list of controls, the `ctrls` in this patch. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Tue, 2014-10-14 at 10:38 +0200, Jan Cholasta wrote:
Dne 14.10.2014 v 10:23 Petr Viktorin napsal(a):
On 10/14/2014 08:51 AM, Jan Cholasta wrote:
Dne 14.10.2014 v 08:37 Martin Kosek napsal(a):
On 10/13/2014 07:23 PM, Nathaniel McCallum wrote:
On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote:
Also, few comments to your current patch set (though the patches
themselves
will probably not land in 4.1):
Patch 0001:
- while it may work (after DS fixes), it adds PostRead for all our
commands,
not just otptoken-add. I would rather have some attribute like
read_dn_from_postread on LDAPObject which defaults to False to
make sure
there is no regression or performance hit with other LDAP calls.
As Honza says later in the mail, this should be an argument for
add_entry (or alternatively an additional add_entry_with_postread
method). Storing settings in data objects leads to trouble – when you
get such an object from somewhere, you never know what an operation on
it will do.
I would prefer add_entry argument rather than a new method, as that's
how find_entries does controls.
In the new code, we actually get a performance gain as the manual post
read is eliminated if the post read control is successful. Only one
issue can arise, which is when the post read control evaluates ACIs
in a
different context than a normal manual read. This problem is well known
and is trivial to fix (s/USERDN/SELFDN/).
That's my point - with such a big change, we can hit many unforeseen
issues and
we are close to deadline. I would rather like to use the PostRead
control only
in otptoken_add command. CCing Petr and Honza to chime in.
I agree it should be opt-in for now. Add a boolean argument to add_entry
as a switch.
+1
Also, I think the add_entry should not return anything; rather the
PostRead result should be merged into the added entry object. Honza,
what do you think?
It should, good point.
In the future it might be useful for add_entry to return a list of
controls, the `ctrls` in this patch.
If we're going to implement temporary workarounds like this in order to
merge this patch, I'd prefer to just wait until 4.2. Without activating
the post read control for all add operations, there is really no benefit
to this patch and added risk.
I propose that for 4.1, we use the attached patch to remove the field
from the UI. Once we have proper ACI/UUID-plugin integration in 389, we
can revisit these patches.
Nathaniel
From 244834182add8e927171f6e9f1b4966c829b7aa4 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Tue, 14 Oct 2014 14:30:01 -0400
Subject: [PATCH] Remove token ID from self-service UI
Also, fix labels to properly use i18n strings for token types.
---
install/ui/src/freeipa/otptoken.js | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/install/ui/src/freeipa/otptoken.js b/install/ui/src/freeipa/otptoken.js
index d5afd25e66c58f4a3b5ce7241b3ddd0ca4f00850..2daeed9b6956921850b527e60b00ad124fb5f3d0 100644
--- a/install/ui/src/freeipa/otptoken.js
+++ b/install/ui/src/freeipa/otptoken.js
@@ -289,14 +289,10 @@ return {
name: 'type',
default_value: 'totp',
options: [
-{ label: 'TOTP', value: 'totp' },
-{ label: 'HOTP', value: 'hotp' }
+{ label: '@i18n:objects.otptoken.type_totp', value: 'totp' },
+{ label: '@i18n:objects.otptoken.type_hotp', value: 'hotp' }
]
},
-{
-name: 'ipatokenuniqueid',
-required: false
-},
'description'
]
}
--
2.1.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/10/2014 05:43 PM, Nathaniel McCallum wrote: As a result of this ongoing conversation, I have opened two 389 bugs: 1. Post Read - https://fedorahosted.org/389/ticket/47924 2. UUID ACIs - https://fedorahosted.org/389/ticket/47925 On Wed, 2014-10-08 at 17:46 -0400, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. Given the number of issues we have with this patch on the DS side, it is likely we will need to go some simpler way for FreeIPA 4.1, in terms just of hiding the option where appropriate. Also, few comments to your current patch set (though the patches themselves will probably not land in 4.1): Patch 0001: - while it may work (after DS fixes), it adds PostRead for all our commands, not just otptoken-add. I would rather have some attribute like read_dn_from_postread on LDAPObject which defaults to False to make sure there is no regression or performance hit with other LDAP calls. - Wider adoption of the PostRead call would be left for future, when we stop doing post-execute LDAP read call and only rely on PostRead result. Patch 0002: - cn=IPA Token Unique IDs,cn=IPA UUID,cn=plugins,cn=config should be created in LDAP update files only. Currently it will not be created on upgrades. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: On 10/10/2014 05:43 PM, Nathaniel McCallum wrote: As a result of this ongoing conversation, I have opened two 389 bugs: 1. Post Read - https://fedorahosted.org/389/ticket/47924 2. UUID ACIs - https://fedorahosted.org/389/ticket/47925 On Wed, 2014-10-08 at 17:46 -0400, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. Given the number of issues we have with this patch on the DS side, it is likely we will need to go some simpler way for FreeIPA 4.1, in terms just of hiding the option where appropriate. We have solved the first DS issue via a sensible workaround. Attached are two new patches. These take into account your feedback below and incorporate the aforementioned workaround. The only thing these patches lack is the tightening of the ACI (problem #2 in the first email). Merging these patches I believe provides benefits over our current code, even though we don't get the final benefit of forcing normal users to use autogeneration. If we test/merge these now, then when the second DS problem is solved, we can simply update the ACI independently via a trivial second patch (s/\*/autogenerate/). Also, few comments to your current patch set (though the patches themselves will probably not land in 4.1): Patch 0001: - while it may work (after DS fixes), it adds PostRead for all our commands, not just otptoken-add. I would rather have some attribute like read_dn_from_postread on LDAPObject which defaults to False to make sure there is no regression or performance hit with other LDAP calls. In the new code, we actually get a performance gain as the manual post read is eliminated if the post read control is successful. Only one issue can arise, which is when the post read control evaluates ACIs in a different context than a normal manual read. This problem is well known and is trivial to fix (s/USERDN/SELFDN/). - Wider adoption of the PostRead call would be left for future, when we stop doing post-execute LDAP read call and only rely on PostRead result. This is already integrated. Patch 0002: - cn=IPA Token Unique IDs,cn=IPA UUID,cn=plugins,cn=config should be created in LDAP update files only. Currently it will not be created on upgrades. Fixed. I believe the following patches are ready for review. Should we review on this thread? Or should I create separate threads for the patches? Nathaniel From ae10d13b3f5e3f9635463d38f72d8a0f06f6ffbe Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Wed, 8 Oct 2014 14:39:18 -0400 Subject: [PATCH 1/2] Use post read control on add operations By adding the post read control, we gain two
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn = ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread works if I use USERDN or SELFDN. Please let me know the version of 389-ds that you are testing, I will try on that branch That is not really the same test at all.
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/10/2014 03:58 PM, thierry bordaz wrote: On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn =ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread works if I use USERDN or SELFDN. Please let me know the version of 389-ds that you are testing, I will try on that
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: On 10/10/2014 03:58 PM, thierry bordaz wrote: On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn =ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread works if I use USERDN or SELFDN. Please let me know the version of 389-ds that
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/10/2014 05:16 PM, thierry bordaz wrote: On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: On 10/10/2014 03:58 PM, thierry bordaz wrote: On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn =ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread works if I use USERDN or SELFDN.
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Fri, 2014-10-10 at 17:30 +0200, Ludwig Krispenz wrote: On 10/10/2014 05:16 PM, thierry bordaz wrote: On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: On 10/10/2014 03:58 PM, thierry bordaz wrote: On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn = ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter =
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
https://fedorahosted.org/389/ticket/47924 is it possible to reproduce without IPA ? Perhaps. You'd need the OTP schema and ACIs from FreeIPA, unless you can find another way to reproduce it. well, did think about it again, we probaly also would need all the plugins, so could be difficult Something curious going on that make ACL_EvalTestRights return something different that ACL_RES_ALLOW. Did you already open a ticket for this problem ? thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Fri, 2014-10-10 at 17:38 +0200, Ludwig Krispenz wrote: https://fedorahosted.org/389/ticket/47924 is it possible to reproduce without IPA ? Perhaps. You'd need the OTP schema and ACIs from FreeIPA, unless you can find another way to reproduce it. well, did think about it again, we probaly also would need all the plugins, so could be difficult I'm not sure you need plugins. You do to make OTP authentication work. But we don't care about that. We just care if add returns the post read control. That should be doable with just schema and ACIs. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/10/2014 05:30 PM, Ludwig Krispenz wrote: On 10/10/2014 05:16 PM, thierry bordaz wrote: On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: On 10/10/2014 03:58 PM, thierry bordaz wrote: On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn =ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
As a result of this ongoing conversation, I have opened two 389 bugs: 1. Post Read - https://fedorahosted.org/389/ticket/47924 2. UUID ACIs - https://fedorahosted.org/389/ticket/47925 On Wed, 2014-10-08 at 17:46 -0400, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. ___ 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] [HELP] Regular users should not be able to add OTP tokens with custom name
On Fri, 10 Oct 2014 17:38:46 +0200 Ludwig Krispenz lkris...@redhat.com wrote: https://fedorahosted.org/389/ticket/47924 is it possible to reproduce without IPA ? Perhaps. You'd need the OTP schema and ACIs from FreeIPA, unless you can find another way to reproduce it. well, did think about it again, we probaly also would need all the plugins, so could be difficult Just a wild guess, for some reason the post-read evaluation is using some cached evaluation of the add. I think the key part here is that we *change* the DN which is key part in determining the access control. I wounder if you can reproduce in 389ds using the DNA plugin ? Use the magic value to generate a number and use the value in the add and read ACIs so that the ADD works only with the magic value. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
aci: (targetfilter = (objectClass=ipaToken))(targetattrs = objectclass || d escription || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNo tBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSer ial || ipatokenOwner)(version 3.0; acl *Users/managers can read basic token* info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or use rattr = managedBy#USERDN;) ... [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Processed attr:managedBy for entry:ipatokenuniqueid=bar,cn=otp,dc=example,dc=com [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 1. Evaluating ALLOW aci(11) *Users/managers can read basic token info* [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in cache [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 2. Evaluating ALLOW aci(19) Admin can manage any entry [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in cache [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= Admin can manage any entry, acidn=dc=example,dc=com [09/Oct/2014:21:34:59 -0400] - process_read_entry_controls: access to entry not allowed (ipatokenuniqueid=bar,cn=otp,dc=example,dc=com) But for some reason, it evaluations of the READ access was not accepted. the key is READ SKIP, looks like it is using cached evaluation of the acis, where the aci did not apply. aci caching is Exact. well, I think I've been a bit too fast, the READ SKIP is only logged from the second attribute on, so caching was ok, but the wrong result was cached. What really is strange is these lines: [09/Oct/2014:21:34:58 -0400] NSACLPlugin - 1. Evaluating ALLOW aci(11) Users/managers can read basic token info [09/Oct/2014:21:34:58 -0400] NSACLPlugin - Attr:ipatokenOwner [09/Oct/2014:21:34:58 -0400] NSACLPlugin - ACL info: userdnattr does not allow ADD permission at level 0. [09/Oct/2014:21:34:58 -0400] NSACLPlugin - Returning UNDEFINED for userdnattr evaluation. why ADD, why UNDEFINED ? Now If I create two entries x/y and their associated ipatoken tokenX/tokenY and play updating x update tokenX then y updates tokenY x update tokenX then x updates tokenY y update tokenY then x updates tokenX ... each time I got the postread. Something curious going on that make ACL_EvalTestRights return something different that ACL_RES_ALLOW. Did you already open a ticket for this problem ? thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. The only ACI I found that match this target is: |aci: (targetfilter= (objectClass=ipaToken)) (targetattrs= objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version3.0; aclUsers/managers can read basic token info; allow(read, search, compare) userattr= ipatokenOwner#USERDN or userattr= managedBy#USERDN;)| Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. It may not querying all attributes, but just search the first one it can read. As it finds none of them you get the message for all attributes. thanks thierry 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Wed, 08 Oct 2014 17:46:01 -0400 Nathaniel McCallum npmccal...@redhat.com wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. Can you show an example ldif ? I wonder if you are setting the owner ? 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. I would expect the same, can someone on the DS team comment ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/09/2014 03:13 PM, Simo Sorce wrote: On Wed, 08 Oct 2014 17:46:01 -0400 Nathaniel McCallum npmccal...@redhat.com wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. Can you show an example ldif ? I wonder if you are setting the owner ? 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. I would expect the same, can someone on the DS team comment ? acis are always applied before the entry is sent to the client. the control is added when the result is sent and for the postop control it gets the POST_OP entry and checks read access to teh entry Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Thu, 09 Oct 2014 16:06:06 +0200 Ludwig Krispenz lkris...@redhat.com wrote: On 10/09/2014 03:13 PM, Simo Sorce wrote: On Wed, 08 Oct 2014 17:46:01 -0400 Nathaniel McCallum npmccal...@redhat.com wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. Can you show an example ldif ? I wonder if you are setting the owner ? 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. I would expect the same, can someone on the DS team comment ? acis are always applied before the entry is sent to the client. the control is added when the result is sent and for the postop control it gets the POST_OP entry and checks read access to teh entry So you think the whole add was denied because the post-read couldn't read back the entry ? Then fixing the read-related issue is all we need ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/09/2014 04:27 PM, Simo Sorce wrote: On Thu, 09 Oct 2014 16:06:06 +0200 Ludwig Krispenz lkris...@redhat.com wrote: On 10/09/2014 03:13 PM, Simo Sorce wrote: On Wed, 08 Oct 2014 17:46:01 -0400 Nathaniel McCallum npmccal...@redhat.com wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. Can you show an example ldif ? I wonder if you are setting the owner ? 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. I would expect the same, can someone on the DS team comment ? acis are always applied before the entry is sent to the client. the control is added when the result is sent and for the postop control it gets the POST_OP entry and checks read access to teh entry So you think the whole add was denied because the post-read couldn't read back the entry ? as far as I understood Nathaniel, the add succeeded, only the control was not returned Then fixing the read-related issue is all we need ? you need an aci allowing to read the postop entry Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Thu, 09 Oct 2014 16:33:20 +0200 Ludwig Krispenz lkris...@redhat.com wrote: On 10/09/2014 04:27 PM, Simo Sorce wrote: On Thu, 09 Oct 2014 16:06:06 +0200 Ludwig Krispenz lkris...@redhat.com wrote: On 10/09/2014 03:13 PM, Simo Sorce wrote: On Wed, 08 Oct 2014 17:46:01 -0400 Nathaniel McCallum npmccal...@redhat.com wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. Can you show an example ldif ? I wonder if you are setting the owner ? 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. I would expect the same, can someone on the DS team comment ? acis are always applied before the entry is sent to the client. the control is added when the result is sent and for the postop control it gets the POST_OP entry and checks read access to teh entry So you think the whole add was denied because the post-read couldn't read back the entry ? as far as I understood Nathaniel, the add succeeded, only the control was not returned Then fixing the read-related issue is all we need ? you need an aci allowing to read the postop entry Btw we could add userattr = creatorsName#SELFDN to the read ACI so that ipatokenOwner/managedby are not strictly needed for post-read ? Does it make sense to do ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/09/2014 04:47 PM, Simo Sorce wrote: On Thu, 09 Oct 2014 16:33:20 +0200 Ludwig Krispenz lkris...@redhat.com wrote: On 10/09/2014 04:27 PM, Simo Sorce wrote: On Thu, 09 Oct 2014 16:06:06 +0200 Ludwig Krispenz lkris...@redhat.com wrote: On 10/09/2014 03:13 PM, Simo Sorce wrote: On Wed, 08 Oct 2014 17:46:01 -0400 Nathaniel McCallum npmccal...@redhat.com wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. Can you show an example ldif ? I wonder if you are setting the owner ? 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. I would expect the same, can someone on the DS team comment ? acis are always applied before the entry is sent to the client. the control is added when the result is sent and for the postop control it gets the POST_OP entry and checks read access to teh entry So you think the whole add was denied because the post-read couldn't read back the entry ? as far as I understood Nathaniel, the add succeeded, only the control was not returned Then fixing the read-related issue is all we need ? you need an aci allowing to read the postop entry Btw we could add userattr = creatorsName#SELFDN to the read ACI so that ipatokenOwner/managedby are not strictly needed for post-read ? Does it make sense to do ? I'm not sure, are there cases when tokenOwner is not set or different from selfdn ? Could anyone else create the token for another user (an admin )? I don't see what the entry really looked like when trying to create the control, and who was self in that scenario. In Nathaniel's post access was denied to uid=otp, is this the tokenwoner ? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz wrote: On 10/09/2014 04:27 PM, Simo Sorce wrote: On Thu, 09 Oct 2014 16:06:06 +0200 Ludwig Krispenz lkris...@redhat.com wrote: On 10/09/2014 03:13 PM, Simo Sorce wrote: On Wed, 08 Oct 2014 17:46:01 -0400 Nathaniel McCallum npmccal...@redhat.com wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. Can you show an example ldif ? I wonder if you are setting the owner ? This is the ldif I used: dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com changetype: add objectClass: top objectClass: ipaToken objectClass: ipaTokenHOTP ipatokenUniqueID: autogenerate ipatokenOTPalgorithm: sha1 ipatokenOTPdigits: 6 ipatokenOTPkey: ipatokenHOTPcounter: 0 ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. I would expect the same, can someone on the DS team comment ? acis are always applied before the entry is sent to the client. the control is added when the result is sent and for the postop control it gets the POST_OP entry and checks read access to teh entry So you think the whole add was denied because the post-read couldn't read back the entry ? as far as I understood Nathaniel, the add succeeded, only the control was not returned Then fixing the read-related issue is all we need ? you need an aci allowing to read the postop entry No. Issue #2 is unrelated to issue #1. In issue #2, the add itself fails. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz wrote: On 10/09/2014 04:27 PM, Simo Sorce wrote: On Thu, 09 Oct 2014 16:06:06 +0200 Ludwig Krispenz lkris...@redhat.com wrote: On 10/09/2014 03:13 PM, Simo Sorce wrote: On Wed, 08 Oct 2014 17:46:01 -0400 Nathaniel McCallum npmccal...@redhat.com wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. Can you show an example ldif ? I wonder if you are setting the owner ? This is the ldif I used: dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com changetype: add objectClass: top objectClass: ipaToken objectClass: ipaTokenHOTP ipatokenUniqueID: autogenerate ipatokenOTPalgorithm: sha1 ipatokenOTPdigits: 6 ipatokenOTPkey: ipatokenHOTPcounter: 0 ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. I would expect the same, can someone on the DS team comment ? acis are always applied before the entry is sent to the client. the control is added when the result is sent and for the postop control it gets the POST_OP entry and checks read access to teh entry So you think the whole add was denied because the post-read couldn't read back the entry ? as far as I understood Nathaniel, the add succeeded, only the control was not returned Then fixing the read-related issue is all we need ? you need an aci allowing to read the postop entry No. Issue #2 is unrelated to issue #1. In issue #2, the add itself fails. is this because of the change from tokenuiqieid=* to tokenuniqueid=autogenerate in the aci, why not stick to* ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Thu, 2014-10-09 at 18:01 +0200, Ludwig Krispenz wrote: On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz wrote: On 10/09/2014 04:27 PM, Simo Sorce wrote: On Thu, 09 Oct 2014 16:06:06 +0200 Ludwig Krispenz lkris...@redhat.com wrote: On 10/09/2014 03:13 PM, Simo Sorce wrote: On Wed, 08 Oct 2014 17:46:01 -0400 Nathaniel McCallum npmccal...@redhat.com wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. Can you show an example ldif ? I wonder if you are setting the owner ? This is the ldif I used: dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com changetype: add objectClass: top objectClass: ipaToken objectClass: ipaTokenHOTP ipatokenUniqueID: autogenerate ipatokenOTPalgorithm: sha1 ipatokenOTPdigits: 6 ipatokenOTPkey: ipatokenHOTPcounter: 0 ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. I would expect the same, can someone on the DS team comment ? acis are always applied before the entry is sent to the client. the control is added when the result is sent and for the postop control it gets the POST_OP entry and checks read access to teh entry So you think the whole add was denied because the post-read couldn't read back the entry ? as far as I understood Nathaniel, the add succeeded, only the control was not returned Then fixing the read-related issue is all we need ? you need an aci allowing to read the postop entry No. Issue #2 is unrelated to issue #1. In issue #2, the add itself fails. is this because of the change from tokenuiqieid=* to tokenuniqueid=autogenerate in the aci? Yes. why not stick to* Because all of this work is done precisely to change from * to autogenerate. The goal is to make it so that ordinary users can only create autogenerated token IDs while admins can specify their own custom token IDs. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. It may not querying all attributes, but just search the first one it can read. As it finds none of them you get the message for all attributes. Right, but why iterate through all possible attributes? It should only iterate through the attributes requested. Whether the user can read a non-requested attribute or not is irrelevant because the attribute was not requested. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. It may not querying all attributes, but just search the first one it can read. As it finds none of them you get the message for all attributes. Right, but why iterate through all possible attributes? It should only iterate through the attributes requested. Whether the user can read a non-requested attribute or not is irrelevant because the attribute was not requested. I think it is iterating from the attributes in the entry. Searching the first one that the authenticated subject is allowed to read. thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/09/2014 06:32 PM, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... +1 could you post the full aci logging not only the summary for the access to the attributes ? I will try to reproduce The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. It may not querying all attributes, but just search the first one it can read. As it finds none of them you get the message for all attributes. Right, but why iterate through all possible attributes? It should only iterate through the attributes requested. Whether the user can read a non-requested attribute or not is irrelevant because the attribute was not requested. I think it is iterating from the attributes in the entry. Searching the first one that the authenticated subject is allowed to read. thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. It may not querying all attributes, but just search the first one it can read. As it finds none of them you get the message for all attributes. Right, but why iterate through all possible attributes? It should only iterate through the attributes requested. Whether the user can read a non-requested attribute or not is irrelevant because the attribute was not requested. I think it is iterating from the attributes in the entry. Searching the first one that the authenticated subject is allowed to read. I agree. The question is: why? Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Thu, 2014-10-09 at 18:38 +0200, Ludwig Krispenz wrote: On 10/09/2014 06:32 PM, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... +1 could you post the full aci logging not only the summary for the access to the attributes ? Attached. [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from cn=anonymous-limits,cn=etc,dc=example,dc=com for (|(objectclass=*)(objectclass=ldapsubentry)) with scope 0 (base) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from uid=otp,cn=users,cn=accounts,dc=example,dc=com for (|(objectclass=*)(objectclass=ldapsubentry)) with scope 0 (base) [08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of service reference [08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of service reference [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com for (|(objectclass=*)(objectclass=ldapsubentry)) with scope 0 (base) [08/Oct/2014:16:54:39 -0400] ipa-lockout-plugin - preop returning 0: success [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from uid=otp,cn=users,cn=accounts,dc=example,dc=com for (|(objectclass=*)(objectclass=ldapsubentry)) with scope 0 (base) [08/Oct/2014:16:54:39 -0400] ipa-pwd-extop - Attempting OTP authentication for 'uid=otp,cn=users,cn=accounts,dc=example,dc=com'. [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from dc=example,dc=com for ((|(objectClass=ipaTokenTOTP)(objectClass=ipaTokenHOTP))(ipatokenOwner=uid=otp,cn=users,cn=accounts,dc=example,dc=com)(|(ipatokenNotBefore=20141008205439Z)(!(ipatokenNotBefore=*)))(|(ipatokenNotAfter=20141008205439Z)(!(ipatokenNotAfter=*)))(|(ipatokenDisabled=FALSE)(!(ipatokenDisabled=* with scope 2 (sub) [08/Oct/2014:16:54:39 -0400] ipa-pwd-extop - kerberos key already present in user entry: uid=otp,cn=users,cn=accounts,dc=example,dc=com [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from uid=otp,cn=users,cn=accounts,dc=example,dc=com for (|(objectclass=*)(objectclass=ldapsubentry)) with scope 0 (base) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from uid=otp,cn=users,cn=accounts,dc=example,dc=com for (|(objectclass=*)(objectclass=ldapsubentry)) with scope 0 (base) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from cn=anonymous-limits,cn=etc,dc=example,dc=com for (|(objectclass=*)(objectclass=ldapsubentry)) with scope 0 (base) [08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of service reference [08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of service reference [08/Oct/2014:16:54:39 -0400] ipa-range-check - Not an ID range object, nothing to do. [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com for (|(objectclass=*)(objectclass=ldapsubentry)) with
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/09/2014 06:53 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:38 +0200, Ludwig Krispenz wrote: On 10/09/2014 06:32 PM, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... +1 could you post the full aci logging not only the summary for the access to the attributes ? Attached. this doesn't look like full acl logging, did you set errorlog-level to include 128 ? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn = ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread works if I use USERDN or SELFDN. Please let me know the version of 389-ds that you are testing, I will try on that branch thanks thierry The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. It may not querying all attributes, but just search the first
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn = ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21)
[Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. From 7e9d847ec2d9b1b3829abbf3ec6961091d378fc7 Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Wed, 8 Oct 2014 16:20:21 -0400 Subject: [PATCH 2/2] Use UUID plugin to generate ipaTokenUniqueIDs This lets us to deny custom ipaTokenUniqueIDs to non-admin users. https://fedorahosted.org/freeipa/ticket/4456 --- install/share/Makefile.am| 1 + install/share/default-aci.ldif | 2 +- install/share/uuid-ipatokenuniqueid.ldif | 11 install/updates/40-otp.update| 3 +- ipalib/plugins/otptoken.py | 47 ++-- ipaserver/install/dsinstance.py | 1 + 6 files changed, 42 insertions(+), 23 deletions(-) create mode 100644 install/share/uuid-ipatokenuniqueid.ldif diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 7d8ceb60e6374e133cfb6e3684bc307dbf313ce7..19bea40c872f148a3a7b8dcafca6e576429e3ace 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -63,6 +63,7 @@ app_DATA =\ user_private_groups.ldif \ host_nis_groups.ldif \ uuid-ipauniqueid.ldif \ + uuid-ipatokenuniqueid.ldif \ modrdn-krbprinc.ldif \ entryusn.ldif \ root-autobind.ldif \ diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif index af7eedb0b92375f893a61ad1fb6e2d7b176389f9..7b6519b291dbaaa075e949317154c047da8f32ce 100644 --- a/install/share/default-aci.ldif +++ b/install/share/default-aci.ldif @@ -96,4 +96,4 @@ aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs = ipatokenOTPalg aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs = ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users/managers can see HOTP details; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) aci: (targetfilter = (objectClass=ipaToken))(targetattrs = description || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial)(version 3.0; acl Managers can write basic token info; allow (write) userattr = managedBy#USERDN;) aci: (targetfilter = (objectClass=ipaToken))(version 3.0; acl Managers can delete tokens; allow (delete) userattr = managedBy#USERDN;) -aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) +aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) diff --git
