Re: [Freeipa-devel] [help]
comments inline. -- 祝： 工作顺利！生活愉快！ -- 长沙研发中心 郑磊 Phone：18684703229 Email：zheng...@kylinos.cn Company：天津麒麟信息技术有限公司 Address：湖南长沙市开福区三一大道工美大厦十四楼 -- Original -- From: "Martin Basti"<mba...@redhat.com>; Date: Wed, Oct 19, 2016 07:56 PM To: "郑磊"<zheng...@kylinos.cn>; "freeipa-devel"<freeipa-devel@redhat.com>; Subject: Re: [Freeipa-devel] [help] Comments inline On 19.10.2016 10:30, 郑磊 wrote: -- 祝： 工作顺利！生活愉快！ -- 长沙研发中心 郑磊 Phone：18684703229 Email：zheng...@kylinos.cn Company：天津麒麟信息技术有限公司 Address：湖南长沙市开福区三一大道工美大厦十四楼 -- Original -- From: "Martin Basti"<mba...@redhat.com>; Date: Wed, Oct 19, 2016 04:03 PM To: "郑磊"<zheng...@kylinos.cn>; "freeipa-devel"<freeipa-devel@redhat.com>; Subject: Re: [Freeipa-devel] [help] On 19.10.2016 03:35, 郑磊 wrote: Hello, In the process of using freeipa, we found a lot of content without Chinese translation. In order to we can better use the platform, we made a Chinese translation. Sorry but I don't see any updates in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750 If you do a custom/manual translations this will not scale and you will do the same every release I have applied to join Chinese translation organization in zanata https://fedora.zanata.org/language/view/zh-CN?dswid=2727, but there is no reply. And I have tried to translate in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750, But there seems to be no permission to modify. Whether I need to put the translation file zh_CN.po to create pull request against freeipa/freeipa on github? No please don't, we always generate .po files from zanata before releases, so all changes are overwritten Ok, let me know how the adding you to zanata continue, if nobody will answer for longer time, I can put you just to freeIPA project as translator. Ok, Thx! If there is still no respond in zanata for a period of time, I will contact you again. I think the translation work for freeipa internationalization promotion also can have certain help. In addition, in use process, we found that when test the corresponding function of operation in the Web interface is not a straightforward logging which needs to query in the background, and it may not be intuitive and convenient. In order to we can intuitively record what we have done the operation in the Web interface, we do the log module plug-ins. webUI is just layer on top of our API calls. I know, What I mean is that no matter we are in API calls mode to manipulate freeipa or Web UI way, we all can intuitive see clearly under the log module. The log module function is to record any of our operation. I think that they can be many caveats (access control, replication, etc.) maybe would be good to see your code (you can send PR) how is you current implementation. Ok, I organize the content first, you'll create a pull request against freeipa/freeipa on github later. Martin -- 祝： 工作顺利！生活愉快！ -- 长沙研发中心 郑磊 Phone：18684703229 Email：zheng...@k
Re: [Freeipa-devel] [help]
Comments inline On 19.10.2016 10:30, 郑磊 wrote: -- 祝： 工作顺利！生活愉快！ -- 长沙研发中心 郑磊 Phone：18684703229 Email：zheng...@kylinos.cn Company：天津麒麟信息技术有限公司 Address：湖南长沙市开福区三一大道工美大厦十四楼 -- Original -- *From: * "Martin Basti"<mba...@redhat.com>; *Date: * Wed, Oct 19, 2016 04:03 PM *To: * "郑磊"<zheng...@kylinos.cn>; "freeipa-devel"<freeipa-devel@redhat.com>; *Subject: * Re: [Freeipa-devel] [help] On 19.10.2016 03:35, 郑磊 wrote: Hello, In the process of using freeipa, we found a lot of content without Chinese translation. In order to we can better use the platform, we made a Chinese translation. Sorry but I don't see any updates in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750 If you do a custom/manual translations this will not scale and you will do the same every release I have applied to join Chinese translation organization in zanata https://fedora.zanata.org/language/view/zh-CN?dswid=2727, but there is no reply. And I have tried to translate in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750, But there seems to be no permission to modify. Whether I need to put the translation file zh_CN.po to create pull request against freeipa/freeipa on github? No please don't, we always generate .po files from zanata before releases, so all changes are overwritten Ok, let me know how the adding you to zanata continue, if nobody will answer for longer time, I can put you just to freeIPA project as translator. I think the translation work for freeipa internationalization promotion also can have certain help. In addition, in use process, we found that when test the corresponding function of operation in the Web interface is not a straightforward logging which needs to query in the background, and it may not be intuitive and convenient. In order to we can intuitively record what we have done the operation in the Web interface, we do the log module plug-ins. webUI is just layer on top of our API calls. I know, What I mean is that no matter we are in API calls mode to manipulate freeipa or Web UI way, we all can intuitive see clearly under the log module. The log module function is to record any of our operation. I think that they can be many caveats (access control, replication, etc.) maybe would be good to see your code (you can send PR) how is you current implementation. Martin -- 祝： 工作顺利！生活愉快！ -- 长沙研发中心 郑磊 Phone：18684703229 Email：zheng...@kylinos.cn Company：天津麒麟信息技术有限公司 Address：湖南长沙市开福区三一大道工美大厦十四楼 -- Original -- *From: * "Martin Basti"<mba...@redhat.com>; *Date: * Tue, Oct 18, 2016 06:50 PM *To: * "郑磊"<zheng...@kylinos.cn>; "freeipa-devel"<freeipa-devel@redhat.com>; *Subject: * Re: [Freeipa-devel] [help] On 18.10.2016 03:28, 郑磊 wrote: Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the Chinese translation to the web interface, also added own log module in web interface, referring to the following screenshots. However, for these changes I don't know how to interact with the community. Is there a administrator to review these changes? Who should I send mail to? Please help me. Thank you very much! Hello, at first you can write here what is your goal, what are your use cases and how do you plan to achieve that. Then, if we agree on solution, you can send code as pull request to our github repository https://github.com/freeipa/freeipa Martin^2 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [help]
-- 祝： 工作顺利！生活愉快！ -- 长沙研发中心 郑磊 Phone：18684703229 Email：zheng...@kylinos.cn Company：天津麒麟信息技术有限公司 Address：湖南长沙市开福区三一大道工美大厦十四楼 -- Original -- From: "Martin Basti"<mba...@redhat.com>; Date: Wed, Oct 19, 2016 04:03 PM To: "郑磊"<zheng...@kylinos.cn>; "freeipa-devel"<freeipa-devel@redhat.com>; Subject: Re: [Freeipa-devel] [help] On 19.10.2016 03:35, 郑磊 wrote: Hello, In the process of using freeipa, we found a lot of content without Chinese translation. In order to we can better use the platform, we made a Chinese translation. Sorry but I don't see any updates in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750 If you do a custom/manual translations this will not scale and you will do the same every release I have applied to join Chinese translation organization in zanata https://fedora.zanata.org/language/view/zh-CN?dswid=2727, but there is no reply. And I have tried to translate in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750, But there seems to be no permission to modify. Whether I need to put the translation file zh_CN.po to create pull request against freeipa/freeipa on github? I think the translation work for freeipa internationalization promotion also can have certain help. In addition, in use process, we found that when test the corresponding function of operation in the Web interface is not a straightforward logging which needs to query in the background, and it may not be intuitive and convenient. In order to we can intuitively record what we have done the operation in the Web interface, we do the log module plug-ins. webUI is just layer on top of our API calls. I know, What I mean is that no matter we are in API calls mode to manipulate freeipa or Web UI way, we all can intuitive see clearly under the log module. The log module function is to record any of our operation. -- 祝： 工作顺利！生活愉快！ -- 长沙研发中心 郑磊 Phone：18684703229 Email：zheng...@kylinos.cn Company：天津麒麟信息技术有限公司 Address：湖南长沙市开福区三一大道工美大厦十四楼 -- Original -- From: "Martin Basti"<mba...@redhat.com>; Date: Tue, Oct 18, 2016 06:50 PM To: "郑磊"<zheng...@kylinos.cn>; "freeipa-devel"<freeipa-devel@redhat.com>; Subject: Re: [Freeipa-devel] [help] On 18.10.2016 03:28, 郑磊 wrote: Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the Chinese translation to the web interface, also added own log module in web interface, referring to the following screenshots. However, for these changes I don't know how to interact with the community. Is there a administrator to review these changes? Who should I send mail to? Please help me. Thank you very much! Hello, at first you can write here what is your goal, what are your use cases and how do you plan to achieve that. Then, if we agree on solution, you can send code as pull request to our github repository https://github.com/freeipa/freeipa Martin^2-- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [help]
On 10/19/2016 10:03 AM, Martin Basti wrote: > > > On 19.10.2016 03:35, 郑磊 wrote: >> Hello, >> In the process of using freeipa, we found a lot of content without Chinese >> translation. In order to we can better use the platform, > >> we made a Chinese translation. > Sorry but I don't see any updates in zanata > https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750 > > If you do a custom/manual translations this will not scale and you will do > the > same every release > >> I think the translation work for freeipa internationalization promotion also >> can have certain help. In addition, in use process, we found that when test >> the corresponding function of operation in the Web interface is not a >> straightforward logging which needs to query in the background, and it may >> not >> be intuitive and convenient. In order to we can intuitively record what we >> have done the operation in the Web interface, we do the log module plug-ins. >> >> > webUI is just layer on top of our API calls. Note that there are some parts of Web UI that aren't translated. Mainly login page. It's because translations are fetched by API call which needs successful auth. > > >> >> >> >> -- >> 祝： >> 工作顺利！生活愉快！ >> -- >> 长沙研发中心 郑磊 >> Phone：18684703229 >> Email：zheng...@kylinos.cn >> Company：天津麒麟信息技术有限公司 >> Address：湖南长沙市开福区三一大道工美大厦十四楼 >> -- Original ---------- >> *From: * "Martin Basti"<mba...@redhat.com>; >> *Date: * Tue, Oct 18, 2016 06:50 PM >> *To: * "郑磊"<zheng...@kylinos.cn>; "freeipa-devel"<freeipa-devel@redhat.com>; >> *Subject: * Re: [Freeipa-devel] [help] >> >> >> >> On 18.10.2016 03:28, 郑磊 wrote: >>> Hello everyone, >>> I'm using freeipa, and having a test and research with the function of >>> freeipa. At the same time, I have carried on the Chinese translation to the >>> web interface, also added own log module in web interface, referring to the >>> following screenshots. However, for these changes I don't know how to >>> interact with the community. Is there a administrator to review these >>> changes? Who should I send mail to? Please help me. Thank you very much! >>> >>> >>> >> >> Hello, >> >> at first you can write here what is your goal, what are your use cases and >> how >> do you plan to achieve that. >> >> Then, if we agree on solution, you can send code as pull request to our >> github >> repository https://github.com/freeipa/freeipa >> >> >> Martin^2 > > > -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [help]
On 19.10.2016 03:35, 郑磊 wrote: Hello, In the process of using freeipa, we found a lot of content without Chinese translation. In order to we can better use the platform, we made a Chinese translation. Sorry but I don't see any updates in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750 If you do a custom/manual translations this will not scale and you will do the same every release I think the translation work for freeipa internationalization promotion also can have certain help. In addition, in use process, we found that when test the corresponding function of operation in the Web interface is not a straightforward logging which needs to query in the background, and it may not be intuitive and convenient. In order to we can intuitively record what we have done the operation in the Web interface, we do the log module plug-ins. webUI is just layer on top of our API calls. -- 祝： 工作顺利！生活愉快！ -- 长沙研发中心 郑磊 Phone：18684703229 Email：zheng...@kylinos.cn Company：天津麒麟信息技术有限公司 Address：湖南长沙市开福区三一大道工美大厦十四楼 -- Original -- *From: * "Martin Basti"<mba...@redhat.com>; *Date: * Tue, Oct 18, 2016 06:50 PM *To: * "郑磊"<zheng...@kylinos.cn>; "freeipa-devel"<freeipa-devel@redhat.com>; *Subject: * Re: [Freeipa-devel] [help] On 18.10.2016 03:28, 郑磊 wrote: Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the Chinese translation to the web interface, also added own log module in web interface, referring to the following screenshots. However, for these changes I don't know how to interact with the community. Is there a administrator to review these changes? Who should I send mail to? Please help me. Thank you very much! Hello, at first you can write here what is your goal, what are your use cases and how do you plan to achieve that. Then, if we agree on solution, you can send code as pull request to our github repository https://github.com/freeipa/freeipa Martin^2 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [help]
Hello, In the process of using freeipa, we found a lot of content without Chinese translation. In order to we can better use the platform, we made a Chinese translation. I think the translation work for freeipa internationalization promotion also can have certain help. In addition, in use process, we found that when test the corresponding function of operation in the Web interface is not a straightforward logging which needs to query in the background, and it may not be intuitive and convenient. In order to we can intuitively record what we have done the operation in the Web interface, we do the log module plug-ins. -- 祝： 工作顺利！生活愉快！ -- 长沙研发中心 郑磊 Phone：18684703229 Email：zheng...@kylinos.cn Company：天津麒麟信息技术有限公司 Address：湖南长沙市开福区三一大道工美大厦十四楼 -- Original -- From: "Martin Basti"<mba...@redhat.com>; Date: Tue, Oct 18, 2016 06:50 PM To: "郑磊"<zheng...@kylinos.cn>; "freeipa-devel"<freeipa-devel@redhat.com>; Subject: Re: [Freeipa-devel] [help] On 18.10.2016 03:28, 郑磊 wrote: Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the Chinese translation to the web interface, also added own log module in web interface, referring to the following screenshots. However, for these changes I don't know how to interact with the community. Is there a administrator to review these changes? Who should I send mail to? Please help me. Thank you very much! Hello, at first you can write here what is your goal, what are your use cases and how do you plan to achieve that. Then, if we agree on solution, you can send code as pull request to our github repository https://github.com/freeipa/freeipa Martin^2-- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [help]
On 18.10.2016 03:28, 郑磊 wrote: Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the Chinese translation to the web interface, also added own log module in web interface, referring to the following screenshots. However, for these changes I don't know how to interact with the community. Is there a administrator to review these changes? Who should I send mail to? Please help me. Thank you very much! Hello, at first you can write here what is your goal, what are your use cases and how do you plan to achieve that. Then, if we agree on solution, you can send code as pull request to our github repository https://github.com/freeipa/freeipa Martin^2 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [help]
Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the Chinese translation to the web interface, also added own log module in web interface, referring to the following screenshots. However, for these changes I don't know how to interact with the community. Is there a administrator to review these changes? Who should I send mail to? Please help me. Thank you very much!-- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
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
Re: [Freeipa-devel] Help define the roles IPA has by default
Dmitri Pal wrote: On 02/11/2011 10:12 AM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/10/2011 07:25 PM, David O'Brien wrote: Dmitri Pal wrote: On 02/10/2011 03:05 PM, Jakub Hrozek wrote: On 02/10/2011 05:12 PM, Rob Crittenden wrote: But what other roles do we need? The mind boggles and rather than dictating what the initial ones will be I'm looking for some guidance/suggestions. thanks rob I'm actually wondering if we need to define many default roles in the upstream project. I'm thinking that every organization will have different needs and different ways of role delegation anyway, so I would rather make sure this feature is well documented with examples and use cases. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I think that a reasonble set of 3 -5 roles and documentation how to change them should be sufficient. I agree. On top of what Dmitri has already sent out, this thread is a really good continuation of documenting delegation, permissions, roles, etc., especially because this area is so different from v1. If we look at it from two perspectives, one being What does IPA need to function?, and the other being What do customers need?, then we can probably come up with a short list and provide some basic use cases, descriptions, and examples. Dmitri's list of 5 is good, although I would suggest settling on a naming format, by which I mean rather than a combination of person-based and role-based names, use a consistent format. Security Architect IPA Administrator are people (faiap), while Helpdesk is a department. Anyway, you get the idea. We've already started with Name, Description, Goals; with a few use cases I can put together short sections with links to existing docs on how to use the relevant commands, or write them as needed. cheers Sounds like a good idea. Well, some of these roles don't really match what we are shipping in v2. There is no place for Application Administrator at all and End User is implicit. So that leaves 3 roles. If we go with these we'll need to add some additional permissions/privileges to support it. If we go with this, here is what we're looking at. Also note that the role IPA Administrator is distinct from the group cn=admins which gives pretty much global access. Those that need additional permissions/privileges are marked with the ticket number. * Security Architect * IPA config (950) * Replication * Define delegation of roles to other, lower-level administrators * IPA Administrator * Define and create groups (and delete?) * Define the relationships between groups (what does this mean?) * Define and create roles for users and groups (what does this mean?) * Create nested groups (I don't know if we can have an aci for this) * Help Desk * Review what groups are enabled on what hosts (what does this mean, all groups are enabled on all hosts, right?) This mean he can read HBAC rules * Set up/manage a user's attributes * Place a user in a specific group * Reset a user password This is a good start but it completely leaves out the following: * Users (helpdesk can modify reset password, nobody can add/delete) * Host management * Service management * Hostgroups * SUDO * HBAC * netgroups * DNS * Automount rob How about this layout Helpdesk Engineer * Edit users * Reset passwords * Add/remove group membership * Troubleshoot the HBAC (in future but not modify the HBAC rules themselves) User administrator - the person who is responsible for creating users and groups. This is instead IPA administrator above. * Users - full control * Groups - full control IT Specialist * Hosts full control * Hostgroups full control * Services full control * DNS full control * Automount IT Security Specialist - includes all of the above + * Netgroups * SUDO * HBAC Security Architect * IPA config * Password policies * Kerberos config * Replication * Define delegation of roles to other, lower-level administrators Did I miss anything? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Any updates on this? I'm up to my neck in Access Control doc at the moment and looking for any and all information, especially when it comes to what IPA provides by default. It gives me something to build on. thanks -- David O'Brien Red Hat Asia Pacific Pty Ltd +61 7 3514 8189 He who asks is a fool for five minutes, but he who does not ask remains a fool forever. ~ Chinese proverb ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Help define the roles IPA has by default
Dmitri Pal wrote: On 02/10/2011 07:25 PM, David O'Brien wrote: Dmitri Pal wrote: On 02/10/2011 03:05 PM, Jakub Hrozek wrote: On 02/10/2011 05:12 PM, Rob Crittenden wrote: But what other roles do we need? The mind boggles and rather than dictating what the initial ones will be I'm looking for some guidance/suggestions. thanks rob I'm actually wondering if we need to define many default roles in the upstream project. I'm thinking that every organization will have different needs and different ways of role delegation anyway, so I would rather make sure this feature is well documented with examples and use cases. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I think that a reasonble set of 3 -5 roles and documentation how to change them should be sufficient. I agree. On top of what Dmitri has already sent out, this thread is a really good continuation of documenting delegation, permissions, roles, etc., especially because this area is so different from v1. If we look at it from two perspectives, one being What does IPA need to function?, and the other being What do customers need?, then we can probably come up with a short list and provide some basic use cases, descriptions, and examples. Dmitri's list of 5 is good, although I would suggest settling on a naming format, by which I mean rather than a combination of person-based and role-based names, use a consistent format. Security Architect IPA Administrator are people (faiap), while Helpdesk is a department. Anyway, you get the idea. We've already started with Name, Description, Goals; with a few use cases I can put together short sections with links to existing docs on how to use the relevant commands, or write them as needed. cheers Sounds like a good idea. Well, some of these roles don't really match what we are shipping in v2. There is no place for Application Administrator at all and End User is implicit. So that leaves 3 roles. If we go with these we'll need to add some additional permissions/privileges to support it. If we go with this, here is what we're looking at. Also note that the role IPA Administrator is distinct from the group cn=admins which gives pretty much global access. Those that need additional permissions/privileges are marked with the ticket number. * Security Architect * IPA config (950) * Replication * Define delegation of roles to other, lower-level administrators * IPA Administrator * Define and create groups (and delete?) * Define the relationships between groups (what does this mean?) * Define and create roles for users and groups (what does this mean?) * Create nested groups (I don't know if we can have an aci for this) * Help Desk * Review what groups are enabled on what hosts (what does this mean, all groups are enabled on all hosts, right?) * Set up/manage a user's attributes * Place a user in a specific group * Reset a user password This is a good start but it completely leaves out the following: * Users (helpdesk can modify reset password, nobody can add/delete) * Host management * Service management * Hostgroups * SUDO * HBAC * netgroups * DNS * Automount rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Help define the roles IPA has by default
On 02/11/2011 10:12 AM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/10/2011 07:25 PM, David O'Brien wrote: Dmitri Pal wrote: On 02/10/2011 03:05 PM, Jakub Hrozek wrote: On 02/10/2011 05:12 PM, Rob Crittenden wrote: But what other roles do we need? The mind boggles and rather than dictating what the initial ones will be I'm looking for some guidance/suggestions. thanks rob I'm actually wondering if we need to define many default roles in the upstream project. I'm thinking that every organization will have different needs and different ways of role delegation anyway, so I would rather make sure this feature is well documented with examples and use cases. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I think that a reasonble set of 3 -5 roles and documentation how to change them should be sufficient. I agree. On top of what Dmitri has already sent out, this thread is a really good continuation of documenting delegation, permissions, roles, etc., especially because this area is so different from v1. If we look at it from two perspectives, one being What does IPA need to function?, and the other being What do customers need?, then we can probably come up with a short list and provide some basic use cases, descriptions, and examples. Dmitri's list of 5 is good, although I would suggest settling on a naming format, by which I mean rather than a combination of person-based and role-based names, use a consistent format. Security Architect IPA Administrator are people (faiap), while Helpdesk is a department. Anyway, you get the idea. We've already started with Name, Description, Goals; with a few use cases I can put together short sections with links to existing docs on how to use the relevant commands, or write them as needed. cheers Sounds like a good idea. Well, some of these roles don't really match what we are shipping in v2. There is no place for Application Administrator at all and End User is implicit. So that leaves 3 roles. If we go with these we'll need to add some additional permissions/privileges to support it. If we go with this, here is what we're looking at. Also note that the role IPA Administrator is distinct from the group cn=admins which gives pretty much global access. Those that need additional permissions/privileges are marked with the ticket number. * Security Architect * IPA config (950) * Replication * Define delegation of roles to other, lower-level administrators * IPA Administrator * Define and create groups (and delete?) * Define the relationships between groups (what does this mean?) * Define and create roles for users and groups (what does this mean?) * Create nested groups (I don't know if we can have an aci for this) * Help Desk * Review what groups are enabled on what hosts (what does this mean, all groups are enabled on all hosts, right?) This mean he can read HBAC rules * Set up/manage a user's attributes * Place a user in a specific group * Reset a user password This is a good start but it completely leaves out the following: * Users (helpdesk can modify reset password, nobody can add/delete) * Host management * Service management * Hostgroups * SUDO * HBAC * netgroups * DNS * Automount rob How about this layout Helpdesk Engineer * Edit users * Reset passwords * Add/remove group membership * Troubleshoot the HBAC (in future but not modify the HBAC rules themselves) User administrator - the person who is responsible for creating users and groups. This is instead IPA administrator above. * Users - full control * Groups - full control IT Specialist * Hosts full control * Hostgroups full control * Services full control * DNS full control * Automount IT Security Specialist - includes all of the above + * Netgroups * SUDO * HBAC Security Architect * IPA config * Password policies * Kerberos config * Replication * Define delegation of roles to other, lower-level administrators Did I miss anything? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Help define the roles IPA has by default
One of the features of IPAv2 is it is much easier to delegate permissions to perform tasks (add, delete, modify, etc). This delegation is broken out into three pieces: * permissions * privileges * roles A permission is a very low-level object that says who can do what to whom. These permissions are grouped together into permissions so one can perform a whole task. This is needed for something like adding a user which requires a couple of different permission such as actually writing the user entry, adding the user to the default group and setting the password. A role is a collection of privileges and the users/groups that are granted those privileges. Right now we are defining a single role, helpdesk, and have assigned no privileges to that yet. I was thinking about just assigning it the ability to reset passwords. But what other roles do we need? The mind boggles and rather than dictating what the initial ones will be I'm looking for some guidance/suggestions. thanks rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Help define the roles IPA has by default
On 02/10/2011 09:42 PM, Rob Crittenden wrote: One of the features of IPAv2 is it is much easier to delegate permissions to perform tasks (add, delete, modify, etc). This delegation is broken out into three pieces: * permissions * privileges * roles A permission is a very low-level object that says who can do what to whom. These permissions are grouped together into permissions so one can perform a whole task. This is needed for something like adding a user which requires a couple of different permission such as actually writing the user entry, adding the user to the default group and setting the password. A role is a collection of privileges and the users/groups that are granted those privileges. Right now we are defining a single role, helpdesk, and have assigned no privileges to that yet. I was thinking about just assigning it the ability to reset passwords. But what other roles do we need? The mind boggles and rather than dictating what the initial ones will be I'm looking for some guidance/suggestions. Thinking about helpdesk and whenever a user joins/leaves a company the helpdesk needs the privileges to add/delete their user accounts. I would suggest all the privileges like: - creating users - resetting passwords - deleting users - disabling user accounts - unlocking user accounts - modifying user accounts Groups are something that are more involved with their respective departments and can be left out for the administrators to decide on if they would like to upgrade the helpdesk role/ or create new roles as per their department listings. thanks rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- regards /shanks ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Help define the roles IPA has by default
Rob Crittenden rcrit...@redhat.com wrote: One of the features of IPAv2 is it is much easier to delegate permissions to perform tasks (add, delete, modify, etc). This delegation is broken out into three pieces: * permissions * privileges * roles A permission is a very low-level object that says who can do what to whom. These permissions are grouped together into permissions so one can perform a whole task. This is needed for something like adding a user which requires a couple of different permission such as actually writing the user entry, adding the user to the default group and setting the password. A role is a collection of privileges and the users/groups that are granted those privileges. Right now we are defining a single role, helpdesk, and have assigned no privileges to that yet. I was thinking about just assigning it the ability to reset passwords. But what other roles do we need? The mind boggles and rather than dictating what the initial ones will be I'm looking for some guidance/suggestions. I think a role called something like IT might be good. Their privileges would cover mainly access to different parts of the network. They should have privilegese to manage: - hosts - hostgroups - hbac rules - sudo rules? - dns - groups (for example to create new group of users which will have access to a particular machine) - services Now looking at the list, this group can be split into two - one managing the hosts/services and one granting users access. Jan ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Help define the roles IPA has by default
On 02/10/2011 01:11 PM, Jan Zeleny wrote: Rob Crittendenrcrit...@redhat.com wrote: One of the features of IPAv2 is it is much easier to delegate permissions to perform tasks (add, delete, modify, etc). This delegation is broken out into three pieces: * permissions * privileges * roles A permission is a very low-level object that says who can do what to whom. These permissions are grouped together into permissions so one can perform a whole task. This is needed for something like adding a user which requires a couple of different permission such as actually writing the user entry, adding the user to the default group and setting the password. A role is a collection of privileges and the users/groups that are granted those privileges. Right now we are defining a single role, helpdesk, and have assigned no privileges to that yet. I was thinking about just assigning it the ability to reset passwords. But what other roles do we need? The mind boggles and rather than dictating what the initial ones will be I'm looking for some guidance/suggestions. I think a role called something like IT might be good. Their privileges would cover mainly access to different parts of the network. They should have privilegese to manage: - hosts - hostgroups - hbac rules - sudo rules? - dns - groups (for example to create new group of users which will have access to a particular machine) - services Now looking at the list, this group can be split into two - one managing the hosts/services and one granting users access. Jan ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Desktop support: needs to be able to add a new host to the server. Probably means they need delete host as well. Can't mess with the user info. Right now, they would also need to be able to create the A record, too. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Help define the roles IPA has by default
On 02/10/2011 05:12 PM, Rob Crittenden wrote: But what other roles do we need? The mind boggles and rather than dictating what the initial ones will be I'm looking for some guidance/suggestions. thanks rob I'm actually wondering if we need to define many default roles in the upstream project. I'm thinking that every organization will have different needs and different ways of role delegation anyway, so I would rather make sure this feature is well documented with examples and use cases. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Help define the roles IPA has by default
On 02/10/2011 03:05 PM, Jakub Hrozek wrote: On 02/10/2011 05:12 PM, Rob Crittenden wrote: But what other roles do we need? The mind boggles and rather than dictating what the initial ones will be I'm looking for some guidance/suggestions. thanks rob I'm actually wondering if we need to define many default roles in the upstream project. I'm thinking that every organization will have different needs and different ways of role delegation anyway, so I would rather make sure this feature is well documented with examples and use cases. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I think that a reasonble set of 3 -5 roles and documentation how to change them should be sufficient. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Help define the roles IPA has by default
Dmitri Pal wrote: On 02/10/2011 03:05 PM, Jakub Hrozek wrote: On 02/10/2011 05:12 PM, Rob Crittenden wrote: But what other roles do we need? The mind boggles and rather than dictating what the initial ones will be I'm looking for some guidance/suggestions. thanks rob I'm actually wondering if we need to define many default roles in the upstream project. I'm thinking that every organization will have different needs and different ways of role delegation anyway, so I would rather make sure this feature is well documented with examples and use cases. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I think that a reasonble set of 3 -5 roles and documentation how to change them should be sufficient. I agree. On top of what Dmitri has already sent out, this thread is a really good continuation of documenting delegation, permissions, roles, etc., especially because this area is so different from v1. If we look at it from two perspectives, one being What does IPA need to function?, and the other being What do customers need?, then we can probably come up with a short list and provide some basic use cases, descriptions, and examples. Dmitri's list of 5 is good, although I would suggest settling on a naming format, by which I mean rather than a combination of person-based and role-based names, use a consistent format. Security Architect IPA Administrator are people (faiap), while Helpdesk is a department. Anyway, you get the idea. We've already started with Name, Description, Goals; with a few use cases I can put together short sections with links to existing docs on how to use the relevant commands, or write them as needed. cheers -- David O'Brien Red Hat Asia Pacific Pty Ltd +61 7 3514 8189 He who asks is a fool for five minutes, but he who does not ask remains a fool forever. ~ Chinese proverb ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
