Re: [Freeipa-devel] [PATCH] 11 - CI - test_forced_client_reenrollment stability fix
On 04/15/2014 05:36 PM, Misnyovszki Adam wrote: On Tue, 15 Apr 2014 12:51:47 +0200 Petr Viktorin pvikt...@redhat.com wrote: On 04/15/2014 12:41 PM, Misnyovszki Adam wrote: Hi, this patch fixes FreeIPA Jenkins CI test freeipa-integration-forced_client_reenrollment-f19, by turning sshfp records into a set, and sorting them before assertion. https://fedorahosted.org/freeipa/ticket/4298 Greets Adam The list.sort() method sorts in-place and returns None, so now the test would not really test anything. Use the sorted() function. You might want to log the value before returning it. My mistake, see the attached, corrected patch. Thanks Adam Adam, Petr - why can't we use a set as I already proposed in the ticket description? set(['i', 'p', 'a']) == set(['a', 'p', 'i']) True Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] kadmin is unresponsive in FreeIPA installation
Did anyone hit https://bugzilla.redhat.com/show_bug.cgi?id=1088163 or is it something specific to my environment? Thanks. -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Ipa-server-install Firewall Support
Dmitri, Thanks for the feedback. I've had a chance to revise the proposal and incorporated your feedback. The first thing to note is that while this implementation is focused on FirewallD support I want to leave open the possibility of supporting other firewalls should anyone else be interested writing the patches. To that end, the module name and command option says firewall not FirewallD. Therefore, I've moved the proposal page to http://www.freeipa.org/page/V4/Firewall_Configuration. I've addressed most of your questions, but here's a brief overview: A, B, C, and D: Corrected E: There's a DBus Method Overview section now. F: I added a statement about error handling. It's hard to go into too much detail about how the various failures will be handled on the wiki. Error handling is very important to me, so don't worry that I'm overlooking it. G: It's really easy to handle existing configurations with FirewallD. (It's actually what makes this possible in comparison to iptables-save scripts.) There will be log messages to notify the user that some services were already allowed to caution that they should not be removed. H and I: There's a restore sub-section in the wiki. This will be easy to handle since the zone uses easily parsable XML. J: Yes. When ipa-server-install invokes the firewall module, it passes through a list of which services should be enabled. K: This will be easy for the firewall configuration module. Just invoke it with the new services. Is there an upgrade script currently, and if so, where is it? I'll add in the proper section there for the firewall. L: This is interesting, and I have a couple of questions on how this should work. 1) Is there an actual use-case when a tool actually would want to check status of a port without correcting it? It seems to me that any sort of is_port_open() call that returned False would be immediately followed by open_port(). If that's the case, then why not just roll them into one operation? There won't be any firewall reload if no modifications take place, so there's no cost to combining them. We could also find a middle ground where there's only one method with a default parameter open_port(..., auto_add=True). 2) Will these tools be executed as root? To query NM and FirewallD, I have to connect to the system bus, which by default, won't allow access from other users without additional authorization. If non-privileged users need to query the firewall configuration, I'll need to look at the DBus policy more closely. 3) Could you point me at a similar tool that has this check and modify behavior? Thanks, Justin On Wed, Apr 9, 2014 at 7:57 PM, Dmitri Pal d...@redhat.com wrote: On 04/08/2014 02:42 PM, Rob Crittenden wrote: Justin Brown wrote: Dmitri, I'd be more than happy to, but I'm having trouble figuring out where it should go. Could you send me a link to a similar design page? I'd put it under here: http://www.freeipa.org/page/V4_Proposals There is a template at http://www.freeipa.org/page/Feature_template So maybe something like http://www.freeipa.org/page/V4/Firewalld Rob has beaten me to it, sorry. I reviewed the page. Pretty informative, thank you. Couple comments: a) No replication impact. b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2 --forwarder=192.168.0.3 I think you want to add the --firewall at the end c) Please be consistent in one place you use freeipa-.. in other just ipa-.. but this is minor d) No commands or config options. e) It would be really nice to have a bit more information about what kind of methods and calls you plan to use to interact with NetworkManager and FirewallD. If you can spell out something like: Logic: Call NM and get blah using method X For each port in the list call FirewallD method Y f) What would be error handling if something goes wrong? Would it abort or create a special message? g) How should it behave if some ports are already open? Will it print a message or do it silently? h) There is actually impact on restore, restore might also now check that ports are configured in the same way they have been. i) We should probably also record in the rollback log the ports that have been opened and close them back if we have to roll back installation or uninstall server. j) We should differentiate whether the CA is being installed and open CA ports only if the CA component is there. k) We are planning to add other components like DRM and TPS We need to figure out if we would have to do something on the upgades when we add those services to add additional ports. l) I suspect that there be cases where different tools and scripts in IPA would need to check and open ports. This means that we should probably create a reusble library that would provide check and update methods. This is so far what came to mind. Thanks for doing it! Really appreciated. Dmitri rob Thanks, Justin On Mon, Apr 7, 2014 at 6:51 PM, Dmitri
Re: [Freeipa-devel] Ipa-server-install Firewall Support
Martin, I think that making the firewall configuration automatic is the best solution. I've updated http://www.freeipa.org/page/V4/Firewall_Configuration for automatic configuration unless --no-firewall is passed. You guys know the user-base better than I do, but I would imagine that users would benefit by making a FreeIPA installation work properly with as few arguments as possible. Thanks, Justin On Thu, Apr 10, 2014 at 1:48 AM, Martin Kosek mko...@redhat.com wrote: On 04/10/2014 02:57 AM, Dmitri Pal wrote: On 04/08/2014 02:42 PM, Rob Crittenden wrote: Justin Brown wrote: ... b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2 --forwarder=192.168.0.3 Let's talk about CLI. Shouldn't we add just one option - --no-firewall? I would assume that we want to open the firewall ports by default *if* the firewalld is running. If firewalld is not running, ipa-server-install would detect it via DBUS and just simply print warning and would not configure anything and could just maybe spit out iptables configuration as Justin mentioned (optional). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
I was looking into ticket https://fedorahosted.org/freeipa/ticket/4054 and experimenting with ACIs allowing privileged users to manage only their own LDAP objects. As already proposed in the Bugzilla, I had success with following ACIs: # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetattr = userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (write) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (delete) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test When I then added a user fbar with permission Add hosts, I was able to do exactly what proposed in the ticket: $ ipa host-add test.example.com --force - Added host test.example.com - Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Password: False Keytab: False Managed by: test.example.com $ ipa host-mod test.example.com --class foo Modified host test.example.com Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Class: foo Password: False Keytab: False Managed by: test.example.com $ ipa host-mod admin.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del admin.example.com ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del test.example.com --- Deleted host test.example.com --- I think this could be pretty powerful also with other LDAP objects. Question is what can be done to allow that to our users. I do not think we should add these ACIs by default as not everybody would like them. But if we enhance our permission API to allow the userattr bind rule, admins could add these ACIs at their wish. IMO the API is not that difficult, something like this could work: $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname --bind-attr-type=USERDN --bind-attr could be more or less free form text to allow creatorsname or parent[0].creatorsname --bind-attr-type would be enum of values USERDN/GROUPDN This should cover most of the basic use cases. Thoughts? -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] kadmin is unresponsive in FreeIPA installation
On Wed, 16 Apr 2014, Martin Kosek wrote: Did anyone hit https://bugzilla.redhat.com/show_bug.cgi?id=1088163 or is it something specific to my environment? I've seen this before several times but couldn't reproduce at all. Latest change to ipa_kdb_passwords.c where the code that does handle the password change was done over a year ago (Jan 2013). Perhaps you can use gdb and break in ipadb_change_pwd()? -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
On 04/16/2014 10:02 AM, Martin Kosek wrote: I was looking into ticket https://fedorahosted.org/freeipa/ticket/4054 and experimenting with ACIs allowing privileged users to manage only their own LDAP objects. As already proposed in the Bugzilla, I had success with following ACIs: # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetattr = userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (write) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (delete) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test When I then added a user fbar with permission Add hosts, I was able to do exactly what proposed in the ticket: $ ipa host-add test.example.com --force - Added host test.example.com - Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Password: False Keytab: False Managed by: test.example.com $ ipa host-mod test.example.com --class foo Modified host test.example.com Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Class: foo Password: False Keytab: False Managed by: test.example.com $ ipa host-mod admin.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del admin.example.com ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del test.example.com --- Deleted host test.example.com --- I think this could be pretty powerful also with other LDAP objects. Question is what can be done to allow that to our users. I do not think we should add these ACIs by default as not everybody would like them. But if we enhance our permission API to allow the userattr bind rule, admins could add these ACIs at their wish. IMO the API is not that difficult, something like this could work: $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname --bind-attr-type=USERDN --bind-attr could be more or less free form text to allow creatorsname or parent[0].creatorsname --bind-attr-type would be enum of values USERDN/GROUPDN This should cover most of the basic use cases. Thoughts? Makes sense. I'd do it around the time we move self-service to permissions. Simo, can you reserve two more OIDs for the attributes? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Do not ask for memberindirect when updating managed permissions
On 11.4.2014 13:31, Petr Viktorin wrote: One of the default_attributes of permission is memberofindirect, a virtual attribute manufactured by ldap2, which is set when a permission is part of a role. When update_entry is called on an entry with memberofindirect, ipaldap tries to add the attribute to LDAP and fails with an objectclass violation. Do not ask for memberindirect when retrieving the entry. CCing Honza since he designs ipaldap. Virtual attributes are often helpful, and in any case IPA uses them a lot and having to filter them out every time is error-prone. Maybe we should add support for them directly in ipaldap -- e.g. an attribute set by `entry.virtual[attr_name] = [x]` would be visible in entry[attr_name] but would not be synced back to LDAP? I would prefer if we stopped abusing LDAPEntry to handle non-LDAP stuff in the future. Your suggestion works in sort of opposite direction, so I can't say I like it. Currently we use LDAPEntry in frontend code directly, but I think that's wrong. There should be a frontend-specific class for this (make ipalib.frontend.Object instantiable?) and LDAPEntry should be used (almost) only in backend code. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
On 16.4.2014 10:20, Petr Viktorin wrote: On 04/16/2014 10:02 AM, Martin Kosek wrote: I was looking into ticket https://fedorahosted.org/freeipa/ticket/4054 and experimenting with ACIs allowing privileged users to manage only their own LDAP objects. As already proposed in the Bugzilla, I had success with following ACIs: # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetattr = userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (write) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (delete) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test When I then added a user fbar with permission Add hosts, I was able to do exactly what proposed in the ticket: $ ipa host-add test.example.com --force - Added host test.example.com - Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Password: False Keytab: False Managed by: test.example.com $ ipa host-mod test.example.com --class foo Modified host test.example.com Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Class: foo Password: False Keytab: False Managed by: test.example.com $ ipa host-mod admin.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del admin.example.com ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del test.example.com --- Deleted host test.example.com --- I think this could be pretty powerful also with other LDAP objects. Question is what can be done to allow that to our users. I do not think we should add these ACIs by default as not everybody would like them. But if we enhance our permission API to allow the userattr bind rule, admins could add these ACIs at their wish. IMO the API is not that difficult, something like this could work: $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname --bind-attr-type=USERDN --bind-attr could be more or less free form text to allow creatorsname or parent[0].creatorsname --bind-attr-type would be enum of values USERDN/GROUPDN This should cover most of the basic use cases. Thoughts? Makes sense. I'd do it around the time we move self-service to permissions. Simo, can you reserve two more OIDs for the attributes? I don't think we need creatorsName, we already have managedBy. Or am I missing something? Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
On 04/16/2014 07:48 AM, Martin Kosek wrote:
On 04/15/2014 06:10 PM, Ludwig Krispenz wrote:
On 04/15/2014 05:45 PM, Ludwig Krispenz wrote:
On 04/15/2014 05:10 PM, Martin Kosek wrote:
On 04/15/2014 05:08 PM, Simo Sorce wrote:
On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote:
On 04/15/2014 03:16 PM, Simo Sorce wrote:
On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote:
On 04/15/2014 09:43 AM, Martin Kosek wrote:
On 04/15/2014 09:38 AM, Martin Kosek wrote:
On 04/14/2014 07:18 PM, Simo Sorce wrote:
On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote:
Hello,
The first patch adds default read permissions to krbtpolicy.
Since the
plugin manages entries in two trees, there are two
permissions. Since
two permissions are needed to cover krbtpolicy, it can't be
used as a
permission's --type.
The permissions are added to a new privilege, 'Kerberos
Ticket Policy
Readers'.
The second patch adds an ACI for reading the Kerberos realm
name. Since
client enrollment won't work without this, I don't see a
reason for
having it managed by a permission.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for
u'Testperm_RN'
using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line
197, in
runTest
self.test(*self.arg)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 301, in
lambda
func = lambda: self.check(nice, **test)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 319, in
check
self.check_output(nice, cmd, args, options, expected,
extra_check)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 359, in
check_output
assert_deepequal(expected, got, nice)
File /root/freeipa-master/ipatests/util.py, line 344, in
assert_deepequal
assert_deepequal(e_sub, g_sub, doc, stack + (key,))
File /root/freeipa-master/ipatests/util.py, line 352, in
assert_deepequal
VALUE % (doc, expected, got, stack)
AssertionError: assert_deepequal: expected != got.
test_permission[37]: permission_find: Search for
u'Testperm_RN'
using --subtree
expected = 1
got = 2
path = ('count',)
Thanks for the catch, tests updated.
Otherwise it works fine (krbtpolicy-show for user cannot be
tested yet
as we
miss permissions for users).
Right; I don't think this permission by itself should allow
access to
users. Correct me if that's wrong.
I created a users permission for testing:
ipa permission-add 'allow reading user objectclass' --type
user
--right={read,search,compare} --attrs objectclass --bind all
/me hit Send too soon.
Although 522 works functionally and client now discovers the IPA
server, there
is no path from SUFFIX to cn=REALM for anonymous users.
I would personally change the ACI to
(targetattr = cn || objectclass)(targetfilter =
(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer)))(version
3.0;acl
Anonymous read access to Kerberos container;allow
(read,compare,search)
userdn = ldap:///anyone;;)'
and put it to cn=kerberos,$SUFFIX (which is of krbcontainer
objectclass).
Right, that's necessary for UIs to list the container.
Simo, are you okay with this?
It is no secret that an IPA server has a container named after the
domain. And the REALM name is available unauthenticated from DNS, so
knowledge of it's existence is given.
Therefore I see no problem if anonymous can see the container
exists, as
long as no contents (beyond what we already determined need to
be) are
revealed I see no problem.
Simo.
Patches work fine. The only problem I see that we now expose group
password
policies
# ldapsearch -h `hostname` -x -b
'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn
...
# MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test
cn: MKOSEK-FEDORA20.TEST
# global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn:
cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc
=test
cn: global_policy
# ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn:
cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test
cn: ipausers
...
It seems suboptimal as we now moved access to group password
policy to
special
permission and we probably do not want to leak a list of defined
group
policies.
Question is how to prevent it as the group password policies have
nsContainer
OC. I see 2 options:
1) Update pwpolicy plugin to avoid using nsContainer for group
password
policy
(I do not think it is needed, krbPwdPolicy contains cn attribute
2) Update our container allowing ACI to not display it.
Option 1) would be nice, but I am afraid it would break search in
older
versions which expects the nsContainer OC to be there.
As
Re: [Freeipa-devel] [PATCH] Do not ask for memberindirect when updating managed permissions
On 04/16/2014 10:35 AM, Jan Cholasta wrote: On 11.4.2014 13:31, Petr Viktorin wrote: One of the default_attributes of permission is memberofindirect, a virtual attribute manufactured by ldap2, which is set when a permission is part of a role. When update_entry is called on an entry with memberofindirect, ipaldap tries to add the attribute to LDAP and fails with an objectclass violation. Do not ask for memberindirect when retrieving the entry. CCing Honza since he designs ipaldap. Virtual attributes are often helpful, and in any case IPA uses them a lot and having to filter them out every time is error-prone. Maybe we should add support for them directly in ipaldap -- e.g. an attribute set by `entry.virtual[attr_name] = [x]` would be visible in entry[attr_name] but would not be synced back to LDAP? I would prefer if we stopped abusing LDAPEntry to handle non-LDAP stuff in the future. Your suggestion works in sort of opposite direction, so I can't say I like it. Currently we use LDAPEntry in frontend code directly, but I think that's wrong. There should be a frontend-specific class for this (make ipalib.frontend.Object instantiable?) and LDAPEntry should be used (almost) only in backend code. Right, that's the way to go long-term. Virtual attributes could be a stop-gap solution before we get there, since to remove this from ldap2 we'd need to change all the plugins that use it. Thinking about it more, it probably would be too much work for a workaround. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
On 04/16/2014 12:07 PM, Petr Viktorin wrote:
On 04/16/2014 07:48 AM, Martin Kosek wrote:
On 04/15/2014 06:10 PM, Ludwig Krispenz wrote:
On 04/15/2014 05:45 PM, Ludwig Krispenz wrote:
On 04/15/2014 05:10 PM, Martin Kosek wrote:
On 04/15/2014 05:08 PM, Simo Sorce wrote:
On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote:
On 04/15/2014 03:16 PM, Simo Sorce wrote:
On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote:
On 04/15/2014 09:43 AM, Martin Kosek wrote:
On 04/15/2014 09:38 AM, Martin Kosek wrote:
On 04/14/2014 07:18 PM, Simo Sorce wrote:
On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote:
Hello,
The first patch adds default read permissions to krbtpolicy.
Since the
plugin manages entries in two trees, there are two
permissions. Since
two permissions are needed to cover krbtpolicy, it can't be
used as a
permission's --type.
The permissions are added to a new privilege, 'Kerberos
Ticket Policy
Readers'.
The second patch adds an ACI for reading the Kerberos realm
name. Since
client enrollment won't work without this, I don't see a
reason for
having it managed by a permission.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for
u'Testperm_RN'
using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line
197, in
runTest
self.test(*self.arg)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 301, in
lambda
func = lambda: self.check(nice, **test)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 319, in
check
self.check_output(nice, cmd, args, options, expected,
extra_check)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 359, in
check_output
assert_deepequal(expected, got, nice)
File /root/freeipa-master/ipatests/util.py, line 344, in
assert_deepequal
assert_deepequal(e_sub, g_sub, doc, stack + (key,))
File /root/freeipa-master/ipatests/util.py, line 352, in
assert_deepequal
VALUE % (doc, expected, got, stack)
AssertionError: assert_deepequal: expected != got.
test_permission[37]: permission_find: Search for
u'Testperm_RN'
using --subtree
expected = 1
got = 2
path = ('count',)
Thanks for the catch, tests updated.
Otherwise it works fine (krbtpolicy-show for user cannot be
tested yet
as we
miss permissions for users).
Right; I don't think this permission by itself should allow
access to
users. Correct me if that's wrong.
I created a users permission for testing:
ipa permission-add 'allow reading user objectclass' --type
user
--right={read,search,compare} --attrs objectclass --bind all
/me hit Send too soon.
Although 522 works functionally and client now discovers the IPA
server, there
is no path from SUFFIX to cn=REALM for anonymous users.
I would personally change the ACI to
(targetattr = cn || objectclass)(targetfilter =
(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer)))(version
3.0;acl
Anonymous read access to Kerberos container;allow
(read,compare,search)
userdn = ldap:///anyone;;)'
and put it to cn=kerberos,$SUFFIX (which is of krbcontainer
objectclass).
Right, that's necessary for UIs to list the container.
Simo, are you okay with this?
It is no secret that an IPA server has a container named after the
domain. And the REALM name is available unauthenticated from
DNS, so
knowledge of it's existence is given.
Therefore I see no problem if anonymous can see the container
exists, as
long as no contents (beyond what we already determined need to
be) are
revealed I see no problem.
Simo.
Patches work fine. The only problem I see that we now expose group
password
policies
# ldapsearch -h `hostname` -x -b
'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn
...
# MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test
cn: MKOSEK-FEDORA20.TEST
# global_policy, MKOSEK-FEDORA20.TEST, kerberos,
mkosek-fedora20.test
dn:
cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc
=test
cn: global_policy
# ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn:
cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test
cn: ipausers
...
It seems suboptimal as we now moved access to group password
policy to
special
permission and we probably do not want to leak a list of defined
group
policies.
Question is how to prevent it as the group password policies have
nsContainer
OC. I see 2 options:
1) Update pwpolicy plugin to avoid using nsContainer for group
password
policy
(I do not think it is needed, krbPwdPolicy contains cn attribute
2) Update our container allowing ACI to not display it.
Option 1) would be nice, but I am afraid it would break search in
older
versions
Re: [Freeipa-devel] Ipa-server-install Firewall Support
On 04/16/2014 09:59 AM, Justin Brown wrote: Martin, I think that making the firewall configuration automatic is the best solution. I've updated http://www.freeipa.org/page/V4/Firewall_Configuration for automatic configuration unless --no-firewall is passed. You guys know the user-base better than I do, but I would imagine that users would benefit by making a FreeIPA installation work properly with as few arguments as possible. Thanks, Justin On Thu, Apr 10, 2014 at 1:48 AM, Martin Kosek mko...@redhat.com wrote: On 04/10/2014 02:57 AM, Dmitri Pal wrote: On 04/08/2014 02:42 PM, Rob Crittenden wrote: Justin Brown wrote: ... b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2 --forwarder=192.168.0.3 Let's talk about CLI. Shouldn't we add just one option - --no-firewall? I would assume that we want to open the firewall ports by default *if* the firewalld is running. If firewalld is not running, ipa-server-install would detect it via DBUS and just simply print warning and would not configure anything and could just maybe spit out iptables configuration as Justin mentioned (optional). Martin Right. The default installation option should fit the most users. Which automatic configuration of firewall (when it is present) is the one. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On 04/14/2014 04:00 PM, Simo Sorce wrote: On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: When heading for a lunch today, I had a discussion with Petr3 about ACIs for cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will simply allow all attributes in cn=etc for authenticated users and will just exclude the blacklisted attributes (for context, see ticket #3566). I personally think it is not the best thing to do as it will just move the problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It would be better to add normal ACIs for cn=etc as well. I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it seems straightforward what ACIs would be needed: == dn: cn=etc,SUFFIX - ADD aci allowing reading nsContainer for anonymous, EXCEPT: We can combine this with the general nsContainer read ACI. The problem is that we can only have one target-based exclusion rule. - cn=virtual operations,cn=etc,SUFFIX Could we use a special objectClass rather than nsContainer for these? - cn=masters,cn=ipa,cn=etc,SUFFIX This is the one I'd exclude with the target rule. - cn=Managed Entries,cn=etc,SUFFIX Why exclude this one? Aren't the containers the same in all IPA installs? dn: cn=sysaccounts,cn=etc,SUFFIX - ADD aci allowing reading all attributes but password attributes (people may add unstructured accounts following different objectclasses) I'd rather list the attributes and let people add custom attributes themselves. dn: cn=ipa,cn=etc,SUFFIX - no ACI needed dn: cn=masters,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading hosts (to have it separate from global cn=etc one so that we can once assign it only to ipamasters hostgroup for example) dn: cn=replicas,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading replicas for authenticated users (masters) dn: cn=dna,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading dnaSharedConfig objects for authenticated dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX - no ACI needed dn: cn=ca_renewal,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading for authenticated users (hosts' certmonger) dn: cn=s4u2proxy,cn=etc,SUFFIX - no ACI needed at this point, KDC access it with DM privileges AFAIK dn: cn=ipaConfig,cn=etc,SUFFIX - ADD aci allowing reading ipaConfigObject attributes for authenticated users. We already plan aci allowing writing them dn: cn=ranges,cn=etc,SUFFIX - ADD aci allowing reading ipaIDrange for authenticated users dn: cn=virtual operations,cn=etc,SUFFIX - ADD aci allowing reading/updating virtual operations, assign to RBAC privileges dn: cn=retrieve certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=request certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=request certificate different host,cn=virtual operations,SUFFIX dn: cn=certificate status,cn=virtual operations,cn=etc,SUFFIX dn: cn=revoke certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=certificate remove hold,cn=virtual operations,cn=etc,SUFFIX - no ACI needed dn: cn=Managed Entries,cn=etc,SUFFIX - no ACI needed, not managed by IPA users dn: cn=automember,cn=etc,SUFFIX - ADD standard automembers ACIs (read, write, delete, ...) dn: cn=CAcert,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading cACertificate for anonymous dn: cn=anonymous-limits,cn=etc,SUFFIX - no ACI needed, not managed by IPA users dn: cn=replication,cn=etc,SUFFIX - ADD aci allowing reading for authenticated users (used in ipa-replica-install) dn: cn=Realm Domains,cn=ipa,cn=etc,SUFFIX - no ACI needed, we already added read aci dn: cn=ad,cn=etc,SUFFIX - ADD aci allowing reading ipaNTDomainAttrs for authenticated users (trust settings) == That should be pretty much all. I know that devil hides in details, but I did not see any blocker to skip the chance to add proper ACIs also for cn=etc as well and thus remove the all allowing ACI at all (I am afraid that we would be stuck with cn=etc all-allowing ACI for years otherwise). Comments welcome. Agree with the general plan, let's start with this and add permissions as needed. Simo. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0527 Add managed read permission to idrange
Read access is given to all authenticated users.
--
Petr³
From 1234bfbc321444365cdf7e7b263cf46e1eb25624 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 26 Mar 2014 16:29:16 +0100
Subject: [PATCH] Add managed read permission to idrange
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
ipalib/plugins/idrange.py | 13 +
1 file changed, 13 insertions(+)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index 91d8525dbc0c5a294e3d2782c58ef14af2d5a972..5cc2786ce2debb5646cb06e0ba996d0840fa06fd 100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -161,10 +161,23 @@ class idrange(LDAPObject):
object_name = ('range')
object_name_plural = ('ranges')
object_class = ['ipaIDrange']
+permission_filter_objectclasses = ['ipaidrange']
possible_objectclasses = ['ipadomainidrange', 'ipatrustedaddomainrange']
default_attributes = ['cn', 'ipabaseid', 'ipaidrangesize', 'ipabaserid',
'ipasecondarybaserid', 'ipanttrusteddomainsid',
'iparangetype']
+managed_permissions = {
+'System: Read ID Ranges': {
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'all',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'cn', 'objectclass',
+'ipabaseid', 'ipaidrangesize', 'iparangetype',
+'ipabaserid', 'ipasecondarybaserid', 'ipanttrusteddomainsid',
+},
+},
+}
label = _('ID Ranges')
label_singular = _('ID Range')
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
On 04/16/2014 10:35 AM, Jan Cholasta wrote: On 16.4.2014 10:20, Petr Viktorin wrote: On 04/16/2014 10:02 AM, Martin Kosek wrote: I was looking into ticket https://fedorahosted.org/freeipa/ticket/4054 and experimenting with ACIs allowing privileged users to manage only their own LDAP objects. As already proposed in the Bugzilla, I had success with following ACIs: # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetattr = userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (write) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (delete) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test When I then added a user fbar with permission Add hosts, I was able to do exactly what proposed in the ticket: $ ipa host-add test.example.com --force - Added host test.example.com - Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Password: False Keytab: False Managed by: test.example.com $ ipa host-mod test.example.com --class foo Modified host test.example.com Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Class: foo Password: False Keytab: False Managed by: test.example.com $ ipa host-mod admin.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del admin.example.com ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del test.example.com --- Deleted host test.example.com --- I think this could be pretty powerful also with other LDAP objects. Question is what can be done to allow that to our users. I do not think we should add these ACIs by default as not everybody would like them. But if we enhance our permission API to allow the userattr bind rule, admins could add these ACIs at their wish. IMO the API is not that difficult, something like this could work: $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname --bind-attr-type=USERDN --bind-attr could be more or less free form text to allow creatorsname or parent[0].creatorsname --bind-attr-type would be enum of values USERDN/GROUPDN This should cover most of the basic use cases. Thoughts? Makes sense. I'd do it around the time we move self-service to permissions. Simo, can you reserve two more OIDs for the attributes? I don't think we need creatorsName, we already have managedBy. Or am I missing something? Honza Currently, managedBy is our own attribute where we can put DNs of other host entries that can manage/edit the host. So you are right, you could partially solve this use case with managedBy. User adding a new host would, however, need to pre-fill managedBy with own DN so that it is acknowledged as host manager. On the other side, creatorsName is an LDAP operational attribute filled automatically. So IMO it would fit the use case described in the ticket better. But as you see, there are different approaches to do that, which confirms my intent to only provide API for creating this type of permissions and let user create it himself. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH][DOC] Update Solaris Documentation, add proxy agent, and profile
On 16.4.2014 05:01, Gabe Alford wrote: The following patches update the Solaris documentation and add a proxy agent/profile for Solaris. - Solaris documentation update https://fedorahosted.org/freeipa/ticket/3731 - Patch adds default Proxy Agent and default_secure profile through 20-nss_ldap.update when ipa-server-install is run. https://fedorahosted.org/freeipa/ticket/2561 Thank you Gabe! I think this chapter deserves review from a Solaris expert. Core IPA team doesn't have one so we need to find some victim ... :-) Sigbjorn, would you mind reviewing this patch set? Instructions how to build docs are here: http://www.freeipa.org/page/Contribute/Documentation Thank you very much! -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH][DOC] Fix NFS configuration documentation
Hi, Attached patch attempts to improve NFS configuration section. Please review, if it is OK, I'll prepare patch to update the other parts as we have quite a duplication across the guide. https://fedorahosted.org/freeipa/ticket/4310 -- / Alexander Bokovoy From 825d9b89dc127154c87333dd9f3bc7238fa56b07 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy aboko...@redhat.com Date: Wed, 16 Apr 2014 14:27:58 +0300 Subject: [PATCH] NFS: update instructions to use safe method to transfer the keytab --- src/user_guide/en-US/InstallingClients.xml | 56 ++ 1 file changed, 34 insertions(+), 22 deletions(-) diff --git a/src/user_guide/en-US/InstallingClients.xml b/src/user_guide/en-US/InstallingClients.xml index 1665a6c..f4795c3 100644 --- a/src/user_guide/en-US/InstallingClients.xml +++ b/src/user_guide/en-US/InstallingClients.xml @@ -413,6 +413,8 @@ $ getent group admins/programlisting RPCSVCGSSDARGS=-vvv/programlisting /note + paraKerberos authentication requires that both client and server participating in an exchange have own Kerberos principals. NFS servers are configured by default to use a Kerberos principal named emphasisnfs/server's host name/emphasis. NFS client software constructs NFS server's Kerberos principal by prepending emphasisnfs//emphasis to the server's hostname. The client's Kerberos principal is not that important; as long as KDC permits issuing a ticket towards emphasisnfs/server.example.com/emphasis, the client's Kerberos principal can be used to perform the authentication. For example, an NFS client can connect using emphasishost/client.example.com/emphasis principal or as a specific user./para + paraWhen NFS server machine emphasisnfs.example.com/emphasis is enrolled to IPAA; domain as IPAA; client, a service named emphasisnfs/nfs.example.com/emphasis has to be created by IPAA; administrator and the service key has to be extracted and stored on the NFS server./para orderedlist listitem para @@ -424,22 +426,44 @@ RPCSVCGSSDARGS=-vvv/programlisting para On IPAA; server, add an NFS service principal for the NFS client. /para -programlisting language=Bash[root@server ~]# ipa service-add nfs/ipaclient.example.com@EXAMPLE/programlisting +programlisting language=Bash[root@server ~]# ipa service-add nfs/nfs.example.com@EXAMPLE/programlisting notetitleNOTE/title para - This must be run from a machine with the packageipa-admintools/package package installed so that the commandipa/command command is available. + This command must be run on a machine with the packageipa-admintools/package package installed so that the commandipa/command command is available. /para /note /listitem -listitem + listitem para - On the IPA; server, obtain a keytab for the NFS service principal. + Next we need to obtain a keytab for the NFS service principal. The keytab contains long term Kerberos key which uniquely authenticates emphasisnfs/nfs.example.com/emphasis to the KDC. This key must be protected or otherwise anyone who has access to the key may impersonate the NFS server. Ideally, NFS server is IPAA; client, thus it should already have commandipa-getkeytab/command installed. /para -para - -programlisting language=Bash[root@server ~]# ipa-getkeytab -s ipaserver.example.com -p nfs/ipaclient.example.com@EXAMPLE -k /tmp/krb5.keytab/programlisting - + orderedlist + listitem + para + If NFS server has commandipa-getkeytab/command installed, it is safer to fetch the key directly from the NFS server. Given that IPA;-enrolled machine owns all services associated with it, emphasishost/nfs.example.com/emphasis principal may retrieve the NFS service keytab directly on the NFS server: +
Re: [Freeipa-devel] [PATCH][DOC] Fix NFS configuration documentation
On Wed, 16 Apr 2014, Alexander Bokovoy wrote: Hi, Attached patch attempts to improve NFS configuration section. Please review, if it is OK, I'll prepare patch to update the other parts as we have quite a duplication across the guide. https://fedorahosted.org/freeipa/ticket/4310 To ease the review, I've made compiled version available at http://abbra.fedorapeople.org/.todo/freeipa-docs/#set_up_nfs_with_kerberos Section 3.4.1 is the part about NFS setup. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] kadmin is unresponsive in FreeIPA installation
On 04/16/2014 10:09 AM, Alexander Bokovoy wrote: On Wed, 16 Apr 2014, Martin Kosek wrote: Did anyone hit https://bugzilla.redhat.com/show_bug.cgi?id=1088163 or is it something specific to my environment? I've seen this before several times but couldn't reproduce at all. Latest change to ipa_kdb_passwords.c where the code that does handle the password change was done over a year ago (Jan 2013). Perhaps you can use gdb and break in ipadb_change_pwd()? In the end I strace'd the kadmin and found out this is related to entropy (again) - kadmind was not really started even though it claimed to be and it was blocked reading /dev/random. I added details to the Bugzilla. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0528 Add managed read permission to automount
A single permission granting anonymous read access covers
automountlocation, automountmap, and automountkey.
--
Petr³
From 76e983917332c2a8db89b944e2aab78ea14d5662 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 26 Mar 2014 17:11:23 +0100
Subject: [PATCH] Add managed read permission to automount
A single permission is added to cover automountlocation,
automountmap, and automountkey.
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
ipalib/plugins/automount.py | 15 +++
1 file changed, 15 insertions(+)
diff --git a/ipalib/plugins/automount.py b/ipalib/plugins/automount.py
index 4b94a595743229660e0bb996c453147b22139a37..b961b1c171102a8805afc4517f37ef0aece76ea2 100644
--- a/ipalib/plugins/automount.py
+++ b/ipalib/plugins/automount.py
@@ -208,6 +208,21 @@ class automountlocation(LDAPObject):
default_attributes = ['cn']
label = _('Automount Locations')
label_singular = _('Automount Location')
+managed_permissions = {
+'System: Read Automount Configuration': {
+# Single permission for all automount-related entries
+'non_object': True,
+'ipapermlocation': DN(container_dn, api.env.basedn),
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'anonymous',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'cn', 'objectclass',
+'automountinformation', 'automountkey', 'description',
+'automountmapname', 'description',
+},
+},
+}
takes_params = (
Str('cn',
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Ipa-server-install Firewall Support
On 04/16/2014 09:56 AM, Justin Brown wrote: ... L: This is interesting, and I have a couple of questions on how this should work. 1) Is there an actual use-case when a tool actually would want to check status of a port without correcting it? It seems to me that any sort of is_port_open() call that returned False would be immediately followed by open_port(). If that's the case, then why not just roll them into one operation? There won't be any firewall reload if no modifications take place, so there's no cost to combining them. We could also find a middle ground where there's only one method with a default parameter open_port(..., auto_add=True). I can imagine situations when we would want to see if a port is open in a firewall and then ask user if he wants to automatically open it. In such cases, 2 separate calls would be indeed helpful. 2) Will these tools be executed as root? To query NM and FirewallD, I have to connect to the system bus, which by default, won't allow access from other users without additional authorization. If non-privileged users need to query the firewall configuration, I'll need to look at the DBus policy more closely. In situations when we are about to manipulate ports, I think it is safe to assume we are operating under root account. I think you can have this assumption in your current code and do not deal with additional authorization at this point. We can think about this case when we need it. 3) Could you point me at a similar tool that has this check and modify behavior? There are many situations in FreeIPA interactive wizards where we have a pattern do_action = check_something() if do_action: do_something() For example, ipa-adtrust-install is checking if there are any users without SID assigned and if there are, it offers to run a task to add them. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
On Wed, 2014-04-16 at 10:02 +0200, Martin Kosek wrote: I was looking into ticket https://fedorahosted.org/freeipa/ticket/4054 and experimenting with ACIs allowing privileged users to manage only their own LDAP objects. As already proposed in the Bugzilla, I had success with following ACIs: # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetattr = userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (write) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (delete) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test When I then added a user fbar with permission Add hosts, I was able to do exactly what proposed in the ticket: $ ipa host-add test.example.com --force - Added host test.example.com - Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Password: False Keytab: False Managed by: test.example.com $ ipa host-mod test.example.com --class foo Modified host test.example.com Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Class: foo Password: False Keytab: False Managed by: test.example.com $ ipa host-mod admin.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del admin.example.com ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del test.example.com --- Deleted host test.example.com --- I think this could be pretty powerful also with other LDAP objects. Question is what can be done to allow that to our users. I do not think we should add these ACIs by default as not everybody would like them. But if we enhance our permission API to allow the userattr bind rule, admins could add these ACIs at their wish. IMO the API is not that difficult, something like this could work: $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname --bind-attr-type=USERDN --bind-attr could be more or less free form text to allow creatorsname or parent[0].creatorsname --bind-attr-type would be enum of values USERDN/GROUPDN This should cover most of the basic use cases. Thoughts? Creatorsname is inflexible as you cannot change it, we should probably have a way to add a role/group attribute at add time that would bind the object to specific roles/groups of users, but beyond this details it looks pretty powerful. One issue is how you still limit access to some attributes that you may not want to allow the creator to set or change, for example ipaUniqueId or similar things, that should always be under control of the system. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
On Wed, 2014-04-16 at 10:20 +0200, Petr Viktorin wrote: On 04/16/2014 10:02 AM, Martin Kosek wrote: I was looking into ticket https://fedorahosted.org/freeipa/ticket/4054 and experimenting with ACIs allowing privileged users to manage only their own LDAP objects. As already proposed in the Bugzilla, I had success with following ACIs: # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetattr = userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (write) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (delete) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test When I then added a user fbar with permission Add hosts, I was able to do exactly what proposed in the ticket: $ ipa host-add test.example.com --force - Added host test.example.com - Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Password: False Keytab: False Managed by: test.example.com $ ipa host-mod test.example.com --class foo Modified host test.example.com Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Class: foo Password: False Keytab: False Managed by: test.example.com $ ipa host-mod admin.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del admin.example.com ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del test.example.com --- Deleted host test.example.com --- I think this could be pretty powerful also with other LDAP objects. Question is what can be done to allow that to our users. I do not think we should add these ACIs by default as not everybody would like them. But if we enhance our permission API to allow the userattr bind rule, admins could add these ACIs at their wish. IMO the API is not that difficult, something like this could work: $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname --bind-attr-type=USERDN --bind-attr could be more or less free form text to allow creatorsname or parent[0].creatorsname --bind-attr-type would be enum of values USERDN/GROUPDN This should cover most of the basic use cases. Thoughts? Makes sense. I'd do it around the time we move self-service to permissions. Simo, can you reserve two more OIDs for the attributes? What attributes ? userclass ? Can't we simply use a group/role ? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
On Wed, 2014-04-16 at 13:12 +0200, Martin Kosek wrote: On 04/16/2014 10:35 AM, Jan Cholasta wrote: On 16.4.2014 10:20, Petr Viktorin wrote: On 04/16/2014 10:02 AM, Martin Kosek wrote: I was looking into ticket https://fedorahosted.org/freeipa/ticket/4054 and experimenting with ACIs allowing privileged users to manage only their own LDAP objects. As already proposed in the Bugzilla, I had success with following ACIs: # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetattr = userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (write) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (delete) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test When I then added a user fbar with permission Add hosts, I was able to do exactly what proposed in the ticket: $ ipa host-add test.example.com --force - Added host test.example.com - Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Password: False Keytab: False Managed by: test.example.com $ ipa host-mod test.example.com --class foo Modified host test.example.com Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Class: foo Password: False Keytab: False Managed by: test.example.com $ ipa host-mod admin.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del admin.example.com ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del test.example.com --- Deleted host test.example.com --- I think this could be pretty powerful also with other LDAP objects. Question is what can be done to allow that to our users. I do not think we should add these ACIs by default as not everybody would like them. But if we enhance our permission API to allow the userattr bind rule, admins could add these ACIs at their wish. IMO the API is not that difficult, something like this could work: $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname --bind-attr-type=USERDN --bind-attr could be more or less free form text to allow creatorsname or parent[0].creatorsname --bind-attr-type would be enum of values USERDN/GROUPDN This should cover most of the basic use cases. Thoughts? Makes sense. I'd do it around the time we move self-service to permissions. Simo, can you reserve two more OIDs for the attributes? I don't think we need creatorsName, we already have managedBy. Or am I missing something? Honza Currently, managedBy is our own attribute where we can put DNs of other host entries that can manage/edit the host. So you are right, you could partially solve this use case with managedBy. User adding a new host would, however, need to pre-fill managedBy with own DN so that it is acknowledged as host manager. On the other side, creatorsName is an LDAP operational attribute filled automatically. So IMO it would fit the use case described in the ticket better. But as you see, there are different approaches to do that, which confirms my intent to only provide API for creating this type of permissions and let user create it himself. Agreed. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
On 04/16/2014 02:45 PM, Simo Sorce wrote: On Wed, 2014-04-16 at 10:20 +0200, Petr Viktorin wrote: On 04/16/2014 10:02 AM, Martin Kosek wrote: I was looking into ticket https://fedorahosted.org/freeipa/ticket/4054 and experimenting with ACIs allowing privileged users to manage only their own LDAP objects. As already proposed in the Bugzilla, I had success with following ACIs: # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetattr = userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (write) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (delete) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test When I then added a user fbar with permission Add hosts, I was able to do exactly what proposed in the ticket: $ ipa host-add test.example.com --force - Added host test.example.com - Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Password: False Keytab: False Managed by: test.example.com $ ipa host-mod test.example.com --class foo Modified host test.example.com Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Class: foo Password: False Keytab: False Managed by: test.example.com $ ipa host-mod admin.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del admin.example.com ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del test.example.com --- Deleted host test.example.com --- I think this could be pretty powerful also with other LDAP objects. Question is what can be done to allow that to our users. I do not think we should add these ACIs by default as not everybody would like them. But if we enhance our permission API to allow the userattr bind rule, admins could add these ACIs at their wish. IMO the API is not that difficult, something like this could work: $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname --bind-attr-type=USERDN --bind-attr could be more or less free form text to allow creatorsname or parent[0].creatorsname --bind-attr-type would be enum of values USERDN/GROUPDN This should cover most of the basic use cases. Thoughts? Makes sense. I'd do it around the time we move self-service to permissions. Simo, can you reserve two more OIDs for the attributes? What attributes ? userclass ? Can't we simply use a group/role ? The --bind-attr and --bind-attr-type values will need to be stored in the permission entry, so we'll need ipaPermBindAttr and ipaPermBindAttrType. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
Similarly to automount, a single permission is added for reading all the
trust objects.
Read access is given to all authenticated users.
--
Petr³
From a499784cbea2f1282a07629a94e67e14c14a35d0 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 26 Mar 2014 17:11:23 +0100
Subject: [PATCH] Add managed read permissions to trust
A single permission is added to cover trust, trustconfig, and trustdomain.
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
ipalib/plugins/trust.py | 23 +++
1 file changed, 23 insertions(+)
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index f57cf7d891928903fdbee67697b96db4ad2679b7..df69bb82d9c545839f2962d6a1a961f89e6691d3 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -312,6 +312,29 @@ class trust(LDAPObject):
search_display_attributes = ['cn', 'ipantflatname',
'ipanttrusteddomainsid', 'ipanttrusttype',
'ipantsidblacklistincoming', 'ipantsidblacklistoutgoing' ]
+managed_permissions = {
+'System: Read Trusts': {
+# Single read permission for all trust-related entries
+'non_object': True,
+'ipapermlocation': DN(container_dn, api.env.basedn),
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'all',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'cn', 'objectclass',
+# ipaNTTrustedDomain:
+'ipanttrusttype', 'ipanttrustattributes',
+'ipanttrustdirection', 'ipanttrustpartner', 'ipantflatname',
+'ipanttrustauthoutgoing', 'ipanttrustauthincoming',
+'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo',
+'ipanttrustposixoffset', 'ipantsupportedencryptiontypes',
+'ipantsidblacklistincoming', 'ipantsidblacklistoutgoing',
+# ipaNTDomainAttrs:
+'ipantsecurityidentifier', 'ipantflatname', 'ipantdomainguid',
+'ipantfallbackprimarygroup',
+},
+},
+}
label = _('Trusts')
label_singular = _('Trust')
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On Wed, 2014-04-16 at 13:31 +0200, Martin Kosek wrote: On 04/16/2014 12:50 PM, Petr Viktorin wrote: On 04/14/2014 04:00 PM, Simo Sorce wrote: On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: When heading for a lunch today, I had a discussion with Petr3 about ACIs for cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will simply allow all attributes in cn=etc for authenticated users and will just exclude the blacklisted attributes (for context, see ticket #3566). I personally think it is not the best thing to do as it will just move the problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It would be better to add normal ACIs for cn=etc as well. I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it seems straightforward what ACIs would be needed: == dn: cn=etc,SUFFIX - ADD aci allowing reading nsContainer for anonymous, EXCEPT: We can combine this with the general nsContainer read ACI. The problem is that we can only have one target-based exclusion rule. Right. - cn=virtual operations,cn=etc,SUFFIX Could we use a special objectClass rather than nsContainer for these? We would need to invent one, like ipaVirtualOperation with one MUST attribute cn and then apply it to all virtual operations and replace nsContainer. It should not be a problem though as we do not provide API to handle the virtual operations. There are very static. Simo, Rob, would you be OK with changing virtual operation objectclass to our own one to have a better control over it? No, in general I am not ok to change objects that already exist in IPA as it make upgrades with new and old replicas break the old replicas. Also we can add new auxiliray classes but removing structural classes is not possible, you would have to delete and recreate the object, and that would be racy too. - cn=masters,cn=ipa,cn=etc,SUFFIX This is the one I'd exclude with the target rule. Ok. - cn=Managed Entries,cn=etc,SUFFIX Why exclude this one? Aren't the containers the same in all IPA installs? Hm, exclusion of this one is probably not needed. User would really only see the containers for Definitions and Templates, not the real configuration (NGP/UGP). dn: cn=sysaccounts,cn=etc,SUFFIX - ADD aci allowing reading all attributes but password attributes (people may add unstructured accounts following different objectclasses) I'd rather list the attributes and let people add custom attributes themselves. Makes sense. Right now, we have 2 types of objects here: 1) system users: simpleSecurityObject objectclass 2) system groups: groupofnames objectclass We can make 2 ACIs, allowing those: - allow reading uid, objectclass of simplesecurityobject to authenticated users - allow reading cn, member, objectclass of groupofnames to authenticated users Yeah we do not need fancy stuff, and we are planning (since forever ?) to give a command to create these entities, so eventually the format will be clear. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
On 04/16/2014 02:49 PM, Petr Viktorin wrote: On 04/16/2014 02:45 PM, Simo Sorce wrote: On Wed, 2014-04-16 at 10:20 +0200, Petr Viktorin wrote: On 04/16/2014 10:02 AM, Martin Kosek wrote: I was looking into ticket https://fedorahosted.org/freeipa/ticket/4054 and experimenting with ACIs allowing privileged users to manage only their own LDAP objects. As already proposed in the Bugzilla, I had success with following ACIs: # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetattr = userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (write) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (delete) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test When I then added a user fbar with permission Add hosts, I was able to do exactly what proposed in the ticket: $ ipa host-add test.example.com --force - Added host test.example.com - Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Password: False Keytab: False Managed by: test.example.com $ ipa host-mod test.example.com --class foo Modified host test.example.com Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Class: foo Password: False Keytab: False Managed by: test.example.com $ ipa host-mod admin.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del admin.example.com ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del test.example.com --- Deleted host test.example.com --- I think this could be pretty powerful also with other LDAP objects. Question is what can be done to allow that to our users. I do not think we should add these ACIs by default as not everybody would like them. But if we enhance our permission API to allow the userattr bind rule, admins could add these ACIs at their wish. IMO the API is not that difficult, something like this could work: $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname --bind-attr-type=USERDN --bind-attr could be more or less free form text to allow creatorsname or parent[0].creatorsname --bind-attr-type would be enum of values USERDN/GROUPDN This should cover most of the basic use cases. Thoughts? Makes sense. I'd do it around the time we move self-service to permissions. Simo, can you reserve two more OIDs for the attributes? What attributes ? userclass ? Can't we simply use a group/role ? The --bind-attr and --bind-attr-type values will need to be stored in the permission entry, so we'll need ipaPermBindAttr and ipaPermBindAttrType. I would personally wait with reserving OID until we create a design of this feature as there are several approaches. We could for example need one more attribute, ipaPermBindAttrDepth we would use for control of the ACI effective depth (mutli valued, values 0-4). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On 04/16/2014 02:55 PM, Simo Sorce wrote: On Wed, 2014-04-16 at 13:31 +0200, Martin Kosek wrote: On 04/16/2014 12:50 PM, Petr Viktorin wrote: On 04/14/2014 04:00 PM, Simo Sorce wrote: On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: When heading for a lunch today, I had a discussion with Petr3 about ACIs for cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will simply allow all attributes in cn=etc for authenticated users and will just exclude the blacklisted attributes (for context, see ticket #3566). I personally think it is not the best thing to do as it will just move the problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It would be better to add normal ACIs for cn=etc as well. I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it seems straightforward what ACIs would be needed: == dn: cn=etc,SUFFIX - ADD aci allowing reading nsContainer for anonymous, EXCEPT: We can combine this with the general nsContainer read ACI. The problem is that we can only have one target-based exclusion rule. Right. - cn=virtual operations,cn=etc,SUFFIX Could we use a special objectClass rather than nsContainer for these? We would need to invent one, like ipaVirtualOperation with one MUST attribute cn and then apply it to all virtual operations and replace nsContainer. It should not be a problem though as we do not provide API to handle the virtual operations. There are very static. Simo, Rob, would you be OK with changing virtual operation objectclass to our own one to have a better control over it? No, in general I am not ok to change objects that already exist in IPA as it make upgrades with new and old replicas break the old replicas. Also we can add new auxiliray classes but removing structural classes is not possible, you would have to delete and recreate the object, and that would be racy too. I see. How about adding a new objectClass in addition to nsContainer, and using a negative targetfilter? - cn=masters,cn=ipa,cn=etc,SUFFIX This is the one I'd exclude with the target rule. Ok. - cn=Managed Entries,cn=etc,SUFFIX Why exclude this one? Aren't the containers the same in all IPA installs? Hm, exclusion of this one is probably not needed. User would really only see the containers for Definitions and Templates, not the real configuration (NGP/UGP). dn: cn=sysaccounts,cn=etc,SUFFIX - ADD aci allowing reading all attributes but password attributes (people may add unstructured accounts following different objectclasses) I'd rather list the attributes and let people add custom attributes themselves. Makes sense. Right now, we have 2 types of objects here: 1) system users: simpleSecurityObject objectclass 2) system groups: groupofnames objectclass We can make 2 ACIs, allowing those: - allow reading uid, objectclass of simplesecurityobject to authenticated users - allow reading cn, member, objectclass of groupofnames to authenticated users Yeah we do not need fancy stuff, and we are planning (since forever ?) to give a command to create these entities, so eventually the format will be clear. Simo. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On Wed, 2014-04-16 at 14:55 +0200, Petr Viktorin wrote:
Similarly to automount, a single permission is added for reading all
the
trust objects.
Read access is given to all authenticated users.
NACK!!
See inline
From a499784cbea2f1282a07629a94e67e14c14a35d0 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 26 Mar 2014 17:11:23 +0100
Subject: [PATCH] Add managed read permissions to trust
A single permission is added to cover trust, trustconfig, and
trustdomain.
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
ipalib/plugins/trust.py | 23 +++
1 file changed, 23 insertions(+)
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index
f57cf7d891928903fdbee67697b96db4ad2679b7..df69bb82d9c545839f2962d6a1a961f89e6691d3
100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -312,6 +312,29 @@ class trust(LDAPObject):
search_display_attributes = ['cn', 'ipantflatname',
'ipanttrusteddomainsid',
'ipanttrusttype',
'ipantsidblacklistincoming',
'ipantsidblacklistoutgoing' ]
+managed_permissions = {
+'System: Read Trusts': {
+# Single read permission for all trust-related entries
+'non_object': True,
+'ipapermlocation': DN(container_dn, api.env.basedn),
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'all',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'cn', 'objectclass',
+# ipaNTTrustedDomain:
+'ipanttrusttype', 'ipanttrustattributes',
+'ipanttrustdirection', 'ipanttrustpartner',
'ipantflatname',
+'ipanttrustauthoutgoing', 'ipanttrustauthincoming',
These 2 attributes here
They contain trust credentials, certainly must not be readbale by any
authenticated user except the trust agents.
+'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo',
+'ipanttrustposixoffset',
'ipantsupportedencryptiontypes',
+'ipantsidblacklistincoming',
'ipantsidblacklistoutgoing',
+# ipaNTDomainAttrs:
+'ipantsecurityidentifier', 'ipantflatname',
'ipantdomainguid',
+'ipantfallbackprimarygroup',
+},
+},
+}
label = _('Trusts')
label_singular = _('Trust')
In general I am not sure all authenticated users need access to all this
info. Alexander ?
Simo.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On Wed, 2014-04-16 at 15:00 +0200, Petr Viktorin wrote: Simo, Rob, would you be OK with changing virtual operation objectclass to our own one to have a better control over it? No, in general I am not ok to change objects that already exist in IPA as it make upgrades with new and old replicas break the old replicas. Also we can add new auxiliray classes but removing structural classes is not possible, you would have to delete and recreate the object, and that would be racy too. I see. How about adding a new objectClass in addition to nsContainer, and using a negative targetfilter? I have no objection to that, but should be last resort if we have no other way IMO, and valid only for objects that are not normally created on a daily basis, as old replicas creating new objects would not know to add the new objectclass. In this case it seem like we should be ok as we do not commonly create these objects, so the chances an old replica creates them are negligible. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH][RFC] 13 - Log pretty-printed request and response
Hi,
this patch enables logging json dumps of request and response, using
the --log-payload switch in ipa cli. RFC tag is to ensure that I
handled the --log-payload switch correctly in ipa cli. Be careful, it
only logs, so --log-payload without -v switch doesn't make the dump
visible in command line, -v does!
https://fedorahosted.org/freeipa/ticket/4233
Thanks
AdamFrom f2230d5200feeb6fa413f4b248736b38ba66d317 Mon Sep 17 00:00:00 2001
From: Adam Misnyovszki amisn...@redhat.com
Date: Wed, 16 Apr 2014 14:58:18 +0200
Subject: [PATCH] Log pretty-printed request and response
With the --log-payload option, every request/response is
logged with json.dumps.
https://fedorahosted.org/freeipa/ticket/4233
---
ipalib/constants.py | 1 +
ipalib/plugable.py | 7 +--
ipalib/rpc.py | 14 +-
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/ipalib/constants.py b/ipalib/constants.py
index 6cc50eacf44678840ad0048a1ef60c05736879cb..6acd7cef549d8b06366ee07adcbeb0a4d1b411d2 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -158,6 +158,7 @@ DEFAULT_CONFIG = (
('interactive', True),
('fallback', True),
('delegate', False),
+('log_payload', False),
# Enable certain optional plugins:
('enable_ra', False),
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index 216f9c08a8b5d22bdb1e7853013967e8fe3f88b0..47e52b662f1421f0476fd7b301cd62043448a50d 100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -597,7 +597,10 @@ class API(DictProxy):
parser.add_option('-f', '--no-fallback', action='store_false',
dest='fallback',
help='Only use the server configured in /etc/ipa/default.conf'
-)
+)
+parser.add_option('--log-payload', action='store_true',
+help='Logs formatted json payload',
+)
return parser
@@ -617,7 +620,7 @@ class API(DictProxy):
pass
overrides[str(key.strip())] = value.strip()
for key in ('conf', 'debug', 'verbose', 'prompt_all', 'interactive',
-'fallback', 'delegate'):
+'fallback', 'delegate', 'log_payload'):
value = getattr(options, key, None)
if value is not None:
overrides[key] = value
diff --git a/ipalib/rpc.py b/ipalib/rpc.py
index 2b47d1c0e25bbeec0dde38089f444e0399e1670e..fa13e5519de51a2a2e341fb94ca452f71087d102 100644
--- a/ipalib/rpc.py
+++ b/ipalib/rpc.py
@@ -738,6 +738,8 @@ class RPCClient(Connectible):
for url in urls:
kw = dict(allow_none=True, encoding='UTF-8')
kw['verbose'] = verbose
+if self.server_proxy_class == JSONServerProxy:
+kw['log_payload'] = self.env.log_payload
if url.startswith('https://'):
if delegate:
transport_class = DelegatedKerbTransport
@@ -783,6 +785,7 @@ class RPCClient(Connectible):
except Exception, e:
# This shouldn't happen if we have a session but it isn't fatal.
pass
+
return self.create_connection(ccache, verbose, fallback, delegate)
if not fallback:
raise
@@ -900,7 +903,8 @@ class xmlclient(RPCClient):
class JSONServerProxy(object):
-def __init__(self, uri, transport, encoding, verbose, allow_none):
+def __init__(self, uri, transport, encoding, verbose, allow_none,
+log_payload):
type, uri = urllib.splittype(uri)
if type not in (http, https):
raise IOError(unsupported XML-RPC protocol)
@@ -910,6 +914,7 @@ class JSONServerProxy(object):
assert encoding == 'UTF-8'
assert allow_none
self.__verbose = verbose
+self.__log_payload = log_payload
# FIXME: Some of our code requires ServerProxy internals.
# But, xmlrpclib.ServerProxy's _ServerProxy__transport can be accessed
@@ -919,6 +924,10 @@ class JSONServerProxy(object):
def __request(self, name, args):
payload = {'method': unicode(name), 'params': args, 'id': 0}
+if self.__log_payload:
+root_logger.info('Request: %s', json.dumps(payload, sort_keys=True,
+ indent=4))
+
response = self.__transport.request(
self.__host,
self.__handler,
@@ -931,6 +940,9 @@ class JSONServerProxy(object):
except ValueError, e:
raise JSONError(str(e))
+if self.__log_payload:
+root_logger.info('Response: %s', json.dumps(response, sort_keys=True,
+indent=4))
error = response.get('error')
if error:
try:
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
Re: [Freeipa-devel] Draft: Read permissions for user
On 04/15/2014 04:55 PM, Petr Viktorin wrote: Hello, At Devconf, we decided what most of the default read permissions should look like, but we did not get to user. Here is a draft of 4 read permissions. Please comment. Basic info (anonymous): [top] objectclass [person] cn, sn, description [organizationalPerson] title [inetOrgPerson] uid displayName, givenName, initials manager [inetUser] memberOf == We originally specifically hidden memberOf attribute from anonymous users. I think we should continue hiding it. [ipaObject] ipaUniqueID [ipaSshUser] ipaSshPubKey [ipaUserAuthTypeClass] ipaUserAuthType [posixAccount] gecos, gidNumber, homeDirectory, loginShell, uidNumber Details (all authenticated): [person] seeAlso, telephoneNumber [organizationalPerson] fax, l, ou, st, postalCode, street destinationIndicator, internationalISDNNumber, physicalDeliveryOfficeName, postalAddress, postOfficeBox, preferredDeliveryMethod, registeredAddress, teletexTerminalIdentifier, telexNumber, x121Address [inetOrgPerson] carLicense, departmentNumber, employeeNumber, employeeType, preferredLanguage, mail, mobile, pager audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, labeledURI, o, photo, roomNumber, secretary, userCertificate, userPKCS12, userSMIMECertificate, x500UniqueIdentifier [inetUser] inetUserHttpURL, inetUserStatus [ipaUser] userClass I would personally not divide the attributes as basic and detailed. IMO it is our artificial distinction and may vary between deployments. Why would we for example show inetUserHttpURL to authenticated only and ipaSshPublicKey to everyone? My proposal would be to have a permission Read User Information for all attributes above. Kerberos/login-related (all authenticated): [krbPrincipalAux] krbPrincipalName, krbCanonicalName, krbPrincipalAliases, krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange [+] nsAccountLock Ok. So permission Read User Kerberos Attributes? Kerberos-related (user admins only): [krbPrincipalAux] krbLastSuccessfulAuth, krbLastFailedAuth, krbLastPwdChange So permission Read User Kerberos Login Attributes? I think this group should also have: krbLastAdminUnlock krbLoginFailedCount No read permission: [person] userPassword ok [krbPrincipalAux] krbPrincipalKey, krbExtraData, krbPwdHistory ok krbLastAdminUnlock, Move this one. krbLoginFailedCount Move this one. krbPrincipalType Simo? I know we do not user this attribute, but wouldn't it fit in Read User Kerberos Attributes permission? krbPwdPolicyReference This could contain DN to user's password policy attribute. IMO somebody should have a right to read it. Simo, should all authenticated users be able to read it? krbTicketPolicyReference, krbUPEnabled I would treat those the same as krbPwdPolicyReference. [krbTicketPolicyAux] krbMaxRenewableAge, krbMaxTicketLife, krbTicketFlags Ok. This will be readable by people with System: Read User Kerberos Ticket Policy permission. [mepOriginEntry] mepManagedEntry This is used to bind user to it's private group. We use it for example in group-detach command to distinguish between managed and non-managed groups. We may want to show it to all authenticated users. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On Wed, 16 Apr 2014, Simo Sorce wrote:
+'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo',
+'ipanttrustposixoffset',
'ipantsupportedencryptiontypes',
+'ipantsidblacklistincoming',
'ipantsidblacklistoutgoing',
+# ipaNTDomainAttrs:
+'ipantsecurityidentifier', 'ipantflatname',
'ipantdomainguid',
+'ipantfallbackprimarygroup',
+},
+},
+}
label = _('Trusts')
label_singular = _('Trust')
In general I am not sure all authenticated users need access to all this
info. Alexander ?
SSSD needs to read some of this information for subdomains support.
That would be at least host/*@REALM who needs to access it.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
+'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo',
+'ipanttrustposixoffset',
'ipantsupportedencryptiontypes',
+'ipantsidblacklistincoming',
'ipantsidblacklistoutgoing',
+# ipaNTDomainAttrs:
+'ipantsecurityidentifier', 'ipantflatname',
'ipantdomainguid',
+'ipantfallbackprimarygroup',
+},
+},
+}
label = _('Trusts')
label_singular = _('Trust')
In general I am not sure all authenticated users need access to all this
info. Alexander ?
SSSD needs to read some of this information for subdomains support.
That would be at least host/*@REALM who needs to access it.
Can you please list exactly which ones are needed ?
Simo.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Draft: Read permissions for user
On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote: On 04/15/2014 04:55 PM, Petr Viktorin wrote: Hello, At Devconf, we decided what most of the default read permissions should look like, but we did not get to user. Here is a draft of 4 read permissions. Please comment. Basic info (anonymous): [top] objectclass [person] cn, sn, description [organizationalPerson] title [inetOrgPerson] uid displayName, givenName, initials manager [inetUser] memberOf == We originally specifically hidden memberOf attribute from anonymous users. I think we should continue hiding it. [ipaObject] ipaUniqueID [ipaSshUser] ipaSshPubKey [ipaUserAuthTypeClass] ipaUserAuthType [posixAccount] gecos, gidNumber, homeDirectory, loginShell, uidNumber Details (all authenticated): [person] seeAlso, telephoneNumber [organizationalPerson] fax, l, ou, st, postalCode, street destinationIndicator, internationalISDNNumber, physicalDeliveryOfficeName, postalAddress, postOfficeBox, preferredDeliveryMethod, registeredAddress, teletexTerminalIdentifier, telexNumber, x121Address [inetOrgPerson] carLicense, departmentNumber, employeeNumber, employeeType, preferredLanguage, mail, mobile, pager audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, labeledURI, o, photo, roomNumber, secretary, userCertificate, userPKCS12, userSMIMECertificate, x500UniqueIdentifier [inetUser] inetUserHttpURL, inetUserStatus [ipaUser] userClass I would personally not divide the attributes as basic and detailed. IMO it is our artificial distinction and may vary between deployments. Why would we for example show inetUserHttpURL to authenticated only and ipaSshPublicKey to everyone? My proposal would be to have a permission Read User Information for all attributes above. Kerberos/login-related (all authenticated): [krbPrincipalAux] krbPrincipalName, krbCanonicalName, krbPrincipalAliases, krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange [+] nsAccountLock Ok. So permission Read User Kerberos Attributes? Kerberos-related (user admins only): [krbPrincipalAux] krbLastSuccessfulAuth, krbLastFailedAuth, krbLastPwdChange So permission Read User Kerberos Login Attributes? I think this group should also have: krbLastAdminUnlock krbLoginFailedCount +1 No read permission: [person] userPassword ok [krbPrincipalAux] krbPrincipalKey, krbExtraData, krbPwdHistory ok krbLastAdminUnlock, Move this one. krbLoginFailedCount Move this one. krbPrincipalType Simo? I know we do not user this attribute, but wouldn't it fit in Read User Kerberos Attributes permission? Yes, we do not use it yet, but we may want to in the future. krbPwdPolicyReference This could contain DN to user's password policy attribute. IMO somebody should have a right to read it. Simo, should all authenticated users be able to read it? Probably not. In another thread we are trying hard to conceal password policy objects, showing this to everybody would thwart that effort as you'd be able to find out the objects by querying all the ones that reference them. Admin and Help Desk people would need access to it though as they need to be able to inspect and change this attribute. krbTicketPolicyReference, krbUPEnabled I would treat those the same as krbPwdPolicyReference. Yeah, makes sense. [krbTicketPolicyAux] krbMaxRenewableAge, krbMaxTicketLife, krbTicketFlags Ok. This will be readable by people with System: Read User Kerberos Ticket Policy permission. [mepOriginEntry] mepManagedEntry This is used to bind user to it's private group. We use it for example in group-detach command to distinguish between managed and non-managed groups. We may want to show it to all authenticated users. Do we need to ? It is only interesting for internal/administrative operations. 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] kadmin is unresponsive in FreeIPA installation
On Wed, 2014-04-16 at 09:31 +0200, Martin Kosek wrote: Did anyone hit https://bugzilla.redhat.com/show_bug.cgi?id=1088163 or is it something specific to my environment? a lot of people is starting to use libvirtd switches to make entropy available to their VMs or using other in VM entropy generating engines, but I've hit entropy starvatoin myself during installs, so this is normal if you have VMs w/o entropy engines activated. 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] Draft: Read permissions for user
On 04/16/2014 03:41 PM, Simo Sorce wrote: On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote: On 04/15/2014 04:55 PM, Petr Viktorin wrote: ... [mepOriginEntry] mepManagedEntry This is used to bind user to it's private group. We use it for example in group-detach command to distinguish between managed and non-managed groups. We may want to show it to all authenticated users. Do we need to ? It is only interesting for internal/administrative operations. After reading the code closely, I see we mostly decide whether an object is managed or not by present of the mepManagedEntry _objetclass_. Reading attribute may not be required if we do not want to display it. We just need to allow it for people operating group-detach command is it writes to it. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
On Wed, 2014-04-16 at 14:55 +0200, Martin Kosek wrote: On 04/16/2014 02:49 PM, Petr Viktorin wrote: On 04/16/2014 02:45 PM, Simo Sorce wrote: On Wed, 2014-04-16 at 10:20 +0200, Petr Viktorin wrote: On 04/16/2014 10:02 AM, Martin Kosek wrote: I was looking into ticket https://fedorahosted.org/freeipa/ticket/4054 and experimenting with ACIs allowing privileged users to manage only their own LDAP objects. As already proposed in the Bugzilla, I had success with following ACIs: # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetattr = userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (write) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:Modify own hosts;allow (delete) userattr = creatorsName#USERDN;) modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test When I then added a user fbar with permission Add hosts, I was able to do exactly what proposed in the ticket: $ ipa host-add test.example.com --force - Added host test.example.com - Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Password: False Keytab: False Managed by: test.example.com $ ipa host-mod test.example.com --class foo Modified host test.example.com Host name: test.example.com Principal name: host/test.example@mkosek-fedora20.test Class: foo Password: False Keytab: False Managed by: test.example.com $ ipa host-mod admin.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del admin.example.com ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del test.example.com --- Deleted host test.example.com --- I think this could be pretty powerful also with other LDAP objects. Question is what can be done to allow that to our users. I do not think we should add these ACIs by default as not everybody would like them. But if we enhance our permission API to allow the userattr bind rule, admins could add these ACIs at their wish. IMO the API is not that difficult, something like this could work: $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname --bind-attr-type=USERDN --bind-attr could be more or less free form text to allow creatorsname or parent[0].creatorsname --bind-attr-type would be enum of values USERDN/GROUPDN This should cover most of the basic use cases. Thoughts? Makes sense. I'd do it around the time we move self-service to permissions. Simo, can you reserve two more OIDs for the attributes? What attributes ? userclass ? Can't we simply use a group/role ? The --bind-attr and --bind-attr-type values will need to be stored in the permission entry, so we'll need ipaPermBindAttr and ipaPermBindAttrType. I would personally wait with reserving OID until we create a design of this feature as there are several approaches. We could for example need one more attribute, ipaPermBindAttrDepth we would use for control of the ACI effective depth (mutli valued, values 0-4). Agreed, there is no hurry until we have a design page. simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Do not ask for memberindirect when updating managed permissions
On Wed, 2014-04-16 at 10:35 +0200, Jan Cholasta wrote: On 11.4.2014 13:31, Petr Viktorin wrote: One of the default_attributes of permission is memberofindirect, a virtual attribute manufactured by ldap2, which is set when a permission is part of a role. When update_entry is called on an entry with memberofindirect, ipaldap tries to add the attribute to LDAP and fails with an objectclass violation. Do not ask for memberindirect when retrieving the entry. CCing Honza since he designs ipaldap. Virtual attributes are often helpful, and in any case IPA uses them a lot and having to filter them out every time is error-prone. Maybe we should add support for them directly in ipaldap -- e.g. an attribute set by `entry.virtual[attr_name] = [x]` would be visible in entry[attr_name] but would not be synced back to LDAP? I would prefer if we stopped abusing LDAPEntry to handle non-LDAP stuff in the future. Your suggestion works in sort of opposite direction, so I can't say I like it. Currently we use LDAPEntry in frontend code directly, but I think that's wrong. There should be a frontend-specific class for this (make ipalib.frontend.Object instantiable?) and LDAPEntry should be used (almost) only in backend code. +1 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] [PATCH] Do not ask for memberindirect when updating managed permissions
On 04/16/2014 03:52 PM, Simo Sorce wrote: On Wed, 2014-04-16 at 10:35 +0200, Jan Cholasta wrote: On 11.4.2014 13:31, Petr Viktorin wrote: One of the default_attributes of permission is memberofindirect, a virtual attribute manufactured by ldap2, which is set when a permission is part of a role. When update_entry is called on an entry with memberofindirect, ipaldap tries to add the attribute to LDAP and fails with an objectclass violation. Do not ask for memberindirect when retrieving the entry. CCing Honza since he designs ipaldap. Virtual attributes are often helpful, and in any case IPA uses them a lot and having to filter them out every time is error-prone. Maybe we should add support for them directly in ipaldap -- e.g. an attribute set by `entry.virtual[attr_name] = [x]` would be visible in entry[attr_name] but would not be synced back to LDAP? I would prefer if we stopped abusing LDAPEntry to handle non-LDAP stuff in the future. Your suggestion works in sort of opposite direction, so I can't say I like it. Currently we use LDAPEntry in frontend code directly, but I think that's wrong. There should be a frontend-specific class for this (make ipalib.frontend.Object instantiable?) and LDAPEntry should be used (almost) only in backend code. +1 Simo. We are then stuck with Petr's original patch 518 - ACK from me. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On Wed, 16 Apr 2014, Simo Sorce wrote:
On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
+'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo',
+'ipanttrustposixoffset',
'ipantsupportedencryptiontypes',
+'ipantsidblacklistincoming',
'ipantsidblacklistoutgoing',
+# ipaNTDomainAttrs:
+'ipantsecurityidentifier', 'ipantflatname',
'ipantdomainguid',
+'ipantfallbackprimarygroup',
+},
+},
+}
label = _('Trusts')
label_singular = _('Trust')
In general I am not sure all authenticated users need access to all this
info. Alexander ?
SSSD needs to read some of this information for subdomains support.
That would be at least host/*@REALM who needs to access it.
Can you please list exactly which ones are needed ?
SSSD subdomains support needs:
- objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs
- ipaNTFlatName
- ipaNTSecurityIdentifier
- ipaNTTrustedDomainSID
- cn
- objectclass ipaIDRange
- cn
- ipaBaseID
- ipaIDRangeSize
- ipaBaseRID
- ipaSecondaryBaseRID
Simo.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0238] Update .gitignore to skip Eclipse and Autotools file
Hello, Update .gitignore to skip Eclipse and Autotools files. -- Petr^2 Spacek From e16b64e91d2b2153b296d0429d04097ba2823134 Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Wed, 16 Apr 2014 16:00:23 +0200 Subject: [PATCH] Update .gitignore to skip Eclipse and Autotools files Signed-off-by: Petr Spacek pspa...@redhat.com --- .gitignore | 7 +++ 1 file changed, 7 insertions(+) diff --git a/.gitignore b/.gitignore index 519fa809e251b0cb2a933bf24751207b82c4991c..56a9916bff91d8d8fdc0c189cec1451bea52cb31 100644 --- a/.gitignore +++ b/.gitignore @@ -3,16 +3,23 @@ *.swp *~ tags +/build # Autoconf Makefile.in /aclocal.m4 /autom4te.cache +/ar-lib /config.guess /config.h.in /config.sub /configure /depcomp /install-sh /ltmain.sh +/m4 /missing + +# Eclipse +.project +.cproject -- 1.9.0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
On 04/16/2014 12:34 PM, Petr Viktorin wrote:
On 04/16/2014 12:07 PM, Petr Viktorin wrote:
On 04/16/2014 07:48 AM, Martin Kosek wrote:
On 04/15/2014 06:10 PM, Ludwig Krispenz wrote:
On 04/15/2014 05:45 PM, Ludwig Krispenz wrote:
On 04/15/2014 05:10 PM, Martin Kosek wrote:
On 04/15/2014 05:08 PM, Simo Sorce wrote:
On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote:
On 04/15/2014 03:16 PM, Simo Sorce wrote:
On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote:
On 04/15/2014 09:43 AM, Martin Kosek wrote:
On 04/15/2014 09:38 AM, Martin Kosek wrote:
On 04/14/2014 07:18 PM, Simo Sorce wrote:
On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote:
Hello,
The first patch adds default read permissions to krbtpolicy.
Since the
plugin manages entries in two trees, there are two
permissions. Since
two permissions are needed to cover krbtpolicy, it can't be
used as a
permission's --type.
The permissions are added to a new privilege, 'Kerberos
Ticket Policy
Readers'.
The second patch adds an ACI for reading the Kerberos realm
name. Since
client enrollment won't work without this, I don't see a
reason for
having it managed by a permission.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for
u'Testperm_RN'
using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line
197, in
runTest
self.test(*self.arg)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 301, in
lambda
func = lambda: self.check(nice, **test)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 319, in
check
self.check_output(nice, cmd, args, options, expected,
extra_check)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 359, in
check_output
assert_deepequal(expected, got, nice)
File /root/freeipa-master/ipatests/util.py, line 344, in
assert_deepequal
assert_deepequal(e_sub, g_sub, doc, stack + (key,))
File /root/freeipa-master/ipatests/util.py, line 352, in
assert_deepequal
VALUE % (doc, expected, got, stack)
AssertionError: assert_deepequal: expected != got.
test_permission[37]: permission_find: Search for
u'Testperm_RN'
using --subtree
expected = 1
got = 2
path = ('count',)
Thanks for the catch, tests updated.
Otherwise it works fine (krbtpolicy-show for user cannot be
tested yet
as we
miss permissions for users).
Right; I don't think this permission by itself should allow
access to
users. Correct me if that's wrong.
I created a users permission for testing:
ipa permission-add 'allow reading user objectclass' --type
user
--right={read,search,compare} --attrs objectclass --bind all
/me hit Send too soon.
Although 522 works functionally and client now discovers the IPA
server, there
is no path from SUFFIX to cn=REALM for anonymous users.
I would personally change the ACI to
(targetattr = cn || objectclass)(targetfilter =
(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer)))(version
3.0;acl
Anonymous read access to Kerberos container;allow
(read,compare,search)
userdn = ldap:///anyone;;)'
and put it to cn=kerberos,$SUFFIX (which is of krbcontainer
objectclass).
Right, that's necessary for UIs to list the container.
Simo, are you okay with this?
It is no secret that an IPA server has a container named after the
domain. And the REALM name is available unauthenticated from
DNS, so
knowledge of it's existence is given.
Therefore I see no problem if anonymous can see the container
exists, as
long as no contents (beyond what we already determined need to
be) are
revealed I see no problem.
Simo.
Patches work fine. The only problem I see that we now expose group
password
policies
# ldapsearch -h `hostname` -x -b
'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn
...
# MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test
cn: MKOSEK-FEDORA20.TEST
# global_policy, MKOSEK-FEDORA20.TEST, kerberos,
mkosek-fedora20.test
dn:
cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc
=test
cn: global_policy
# ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn:
cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test
cn: ipausers
...
It seems suboptimal as we now moved access to group password
policy to
special
permission and we probably do not want to leak a list of defined
group
policies.
Question is how to prevent it as the group password policies have
nsContainer
OC. I see 2 options:
1) Update pwpolicy plugin to avoid using nsContainer for group
password
policy
(I do not think it is needed,
Re: [Freeipa-devel] [PATCH] 11 - CI - test_forced_client_reenrollment stability fix
On Wed, 16 Apr 2014 07:59:39 +0200
Martin Kosek mko...@redhat.com wrote:
On 04/15/2014 05:36 PM, Misnyovszki Adam wrote:
On Tue, 15 Apr 2014 12:51:47 +0200
Petr Viktorin pvikt...@redhat.com wrote:
On 04/15/2014 12:41 PM, Misnyovszki Adam wrote:
Hi,
this patch fixes FreeIPA Jenkins CI test
freeipa-integration-forced_client_reenrollment-f19, by turning
sshfp records into a set, and sorting them before assertion.
https://fedorahosted.org/freeipa/ticket/4298
Greets
Adam
The list.sort() method sorts in-place and returns None, so now the
test would not really test anything. Use the sorted() function.
You might want to log the value before returning it.
My mistake, see the attached, corrected patch.
Thanks
Adam
Adam, Petr - why can't we use a set as I already proposed in the
ticket description?
set(['i', 'p', 'a']) == set(['a', 'p', 'i'])
True
Martin
Hi,
see the attached patch.
Thanks
AdamFrom 3c6a371b9c4abfead5d55b8655eb7d047054b1c0 Mon Sep 17 00:00:00 2001
From: Adam Misnyovszki amisn...@redhat.com
Date: Wed, 16 Apr 2014 16:18:28 +0200
Subject: [PATCH] CI - test_forced_client_reenrollment stability fix
fixes FreeIPA Jenkins CI test freeipa-integration-forced_client_reenrollment-f19
https://fedorahosted.org/freeipa/ticket/4298
---
ipatests/test_integration/test_forced_client_reenrollment.py | 4
1 file changed, 4 insertions(+)
diff --git a/ipatests/test_integration/test_forced_client_reenrollment.py b/ipatests/test_integration/test_forced_client_reenrollment.py
index 4ba4cda1d4fe509110fffa91e1c13d78b457f64d..cece522f8d81e0de72735f60167393423152c717 100644
--- a/ipatests/test_integration/test_forced_client_reenrollment.py
+++ b/ipatests/test_integration/test_forced_client_reenrollment.py
@@ -256,6 +256,10 @@ class TestForcedClientReenrollment(IntegrationTest):
sshfp_record = line.replace('SSHFP record:', '').strip()
assert sshfp_record, 'SSHFP record not found'
+
+sshfp_record = set(sshfp_record.split(', '))
+self.log.debug(SSHFP record for host %s: %s, client_host, str(sshfp_record))
+
return sshfp_record
def backup_keytab(self):
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0525 Add managed read permissions to automember
On 04/15/2014 02:33 PM, Petr Viktorin wrote: Read access to both rules and definitions is given to a new privilege, 'Automember Readers', as well as the existing 'Automember Task Administrator'. This needs a mild rebase in 40-delegation.update. When I resolved the conflict patch worked fine, no problem found. ACK when you fix the conflict. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0527 Add managed read permission to idrange
On 04/16/2014 01:02 PM, Petr Viktorin wrote: Read access is given to all authenticated users. Works fine, no problem found - ACK. Pushed to master: bb4e47d9ea249d7f3ead460284dd67312cc82bd5 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0528 Add managed read permission to automount
On 04/16/2014 02:14 PM, Petr Viktorin wrote: A single permission granting anonymous read access covers automountlocation, automountmap, and automountkey. This works fine, I am just wondering about the ACI: 1) Simo, are you OK with one ACI covering all automount objects? I personally am, I cannot imagine a situation when somebody allows automount maps but not the automount keys. But on the other hand, we also have separate permissions for sudo commands, sudo command groups, sudo rules... 2) Should we limit the ACI by an objectclass filter? I.e. (|(objectclass=automountmap)(objectclass=automount))? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On 04/16/2014 03:59 PM, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
+'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo',
+'ipanttrustposixoffset',
'ipantsupportedencryptiontypes',
+'ipantsidblacklistincoming',
'ipantsidblacklistoutgoing',
+# ipaNTDomainAttrs:
+'ipantsecurityidentifier', 'ipantflatname',
'ipantdomainguid',
+'ipantfallbackprimarygroup',
+},
+},
+}
label = _('Trusts')
label_singular = _('Trust')
In general I am not sure all authenticated users need access to all this
info. Alexander ?
SSSD needs to read some of this information for subdomains support.
That would be at least host/*@REALM who needs to access it.
Can you please list exactly which ones are needed ?
SSSD subdomains support needs:
- objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs
- ipaNTFlatName
- ipaNTSecurityIdentifier
- ipaNTTrustedDomainSID
- cn
Question is - is there any added value in hiding part of the
trust information from authenticated users? I.e. attributes like
ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this
attribute anyway?), SID blacklists...
If yes, we would need to split this permission in 2 and have one for
authenticated users and one for Trust Adminitrators and Trust Readers.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On Wed, 16 Apr 2014, Martin Kosek wrote:
On 04/16/2014 03:59 PM, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
+'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo',
+'ipanttrustposixoffset',
'ipantsupportedencryptiontypes',
+'ipantsidblacklistincoming',
'ipantsidblacklistoutgoing',
+# ipaNTDomainAttrs:
+'ipantsecurityidentifier', 'ipantflatname',
'ipantdomainguid',
+'ipantfallbackprimarygroup',
+},
+},
+}
label = _('Trusts')
label_singular = _('Trust')
In general I am not sure all authenticated users need access to all this
info. Alexander ?
SSSD needs to read some of this information for subdomains support.
That would be at least host/*@REALM who needs to access it.
Can you please list exactly which ones are needed ?
SSSD subdomains support needs:
- objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs
- ipaNTFlatName
- ipaNTSecurityIdentifier
- ipaNTTrustedDomainSID
- cn
Question is - is there any added value in hiding part of the
trust information from authenticated users? I.e. attributes like
ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this
attribute anyway?), SID blacklists...
Yes. Some of those attributes are needed as internal detail of ipasam --
part of how Samba stores this information taken from specific DCE RPC
structures.
If yes, we would need to split this permission in 2 and have one for
authenticated users and one for Trust Adminitrators and Trust Readers.
Yes. Authenticated users shouldn't get any access to those details:
ipantsupportedencryptiontypes
ipanttrustattributes
ipanttrustauthincoming
ipanttrustauthoutgoing
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On 04/16/2014 05:10 PM, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Martin Kosek wrote:
On 04/16/2014 03:59 PM, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
+'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo',
+'ipanttrustposixoffset',
'ipantsupportedencryptiontypes',
+'ipantsidblacklistincoming',
'ipantsidblacklistoutgoing',
+# ipaNTDomainAttrs:
+'ipantsecurityidentifier', 'ipantflatname',
'ipantdomainguid',
+'ipantfallbackprimarygroup',
+},
+},
+}
label = _('Trusts')
label_singular = _('Trust')
In general I am not sure all authenticated users need access to all this
info. Alexander ?
SSSD needs to read some of this information for subdomains support.
That would be at least host/*@REALM who needs to access it.
Can you please list exactly which ones are needed ?
SSSD subdomains support needs:
- objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs
- ipaNTFlatName
- ipaNTSecurityIdentifier
- ipaNTTrustedDomainSID
- cn
Question is - is there any added value in hiding part of the
trust information from authenticated users? I.e. attributes like
ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this
attribute anyway?), SID blacklists...
Yes. Some of those attributes are needed as internal detail of ipasam --
part of how Samba stores this information taken from specific DCE RPC
structures.
If yes, we would need to split this permission in 2 and have one for
authenticated users and one for Trust Adminitrators and Trust Readers.
Yes. Authenticated users shouldn't get any access to those details:
ipantsupportedencryptiontypes
ipanttrustattributes
ipanttrustauthincoming
ipanttrustauthoutgoing
Ok. I assume that cn=adtrust agents,cn=sysaccounts,SUFFIX system group should
then have this permission assigned so that samba can operate the attributes.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On Wed, 16 Apr 2014, Martin Kosek wrote:
On 04/16/2014 05:10 PM, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Martin Kosek wrote:
On 04/16/2014 03:59 PM, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
+'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo',
+'ipanttrustposixoffset',
'ipantsupportedencryptiontypes',
+'ipantsidblacklistincoming',
'ipantsidblacklistoutgoing',
+# ipaNTDomainAttrs:
+'ipantsecurityidentifier', 'ipantflatname',
'ipantdomainguid',
+'ipantfallbackprimarygroup',
+},
+},
+}
label = _('Trusts')
label_singular = _('Trust')
In general I am not sure all authenticated users need access to all this
info. Alexander ?
SSSD needs to read some of this information for subdomains support.
That would be at least host/*@REALM who needs to access it.
Can you please list exactly which ones are needed ?
SSSD subdomains support needs:
- objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs
- ipaNTFlatName
- ipaNTSecurityIdentifier
- ipaNTTrustedDomainSID
- cn
Question is - is there any added value in hiding part of the
trust information from authenticated users? I.e. attributes like
ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this
attribute anyway?), SID blacklists...
Yes. Some of those attributes are needed as internal detail of ipasam --
part of how Samba stores this information taken from specific DCE RPC
structures.
If yes, we would need to split this permission in 2 and have one for
authenticated users and one for Trust Adminitrators and Trust Readers.
Yes. Authenticated users shouldn't get any access to those details:
ipantsupportedencryptiontypes
ipanttrustattributes
ipanttrustauthincoming
ipanttrustauthoutgoing
Ok. I assume that cn=adtrust agents,cn=sysaccounts,SUFFIX system group should
then have this permission assigned so that samba can operate the attributes.
'adtrust agents' and 'trust administrators' should have read, modify,
delete, and search on cn=trusts.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On 04/16/2014 05:22 PM, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Martin Kosek wrote:
On 04/16/2014 05:10 PM, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Martin Kosek wrote:
On 04/16/2014 03:59 PM, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
+'ipanttrusteddomainsid',
'ipanttrustforesttrustinfo',
+'ipanttrustposixoffset',
'ipantsupportedencryptiontypes',
+'ipantsidblacklistincoming',
'ipantsidblacklistoutgoing',
+# ipaNTDomainAttrs:
+'ipantsecurityidentifier', 'ipantflatname',
'ipantdomainguid',
+'ipantfallbackprimarygroup',
+},
+},
+}
label = _('Trusts')
label_singular = _('Trust')
In general I am not sure all authenticated users need access to all
this
info. Alexander ?
SSSD needs to read some of this information for subdomains support.
That would be at least host/*@REALM who needs to access it.
Can you please list exactly which ones are needed ?
SSSD subdomains support needs:
- objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs
- ipaNTFlatName
- ipaNTSecurityIdentifier
- ipaNTTrustedDomainSID
- cn
Question is - is there any added value in hiding part of the
trust information from authenticated users? I.e. attributes like
ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this
attribute anyway?), SID blacklists...
Yes. Some of those attributes are needed as internal detail of ipasam --
part of how Samba stores this information taken from specific DCE RPC
structures.
If yes, we would need to split this permission in 2 and have one for
authenticated users and one for Trust Adminitrators and Trust Readers.
Yes. Authenticated users shouldn't get any access to those details:
ipantsupportedencryptiontypes
ipanttrustattributes
ipanttrustauthincoming
ipanttrustauthoutgoing
Ok. I assume that cn=adtrust agents,cn=sysaccounts,SUFFIX system group
should
then have this permission assigned so that samba can operate the attributes.
'adtrust agents' and 'trust administrators' should have read, modify,
delete, and search on cn=trusts.
Right. We will probably want to turn most of ACIs in
install/updates/60-trusts.update in managed permissions (i.e. defined in
trust.py) and make adtrust agents and trust admins it's members.
It'd make the ACIs more maintainable and install/updates/60-trusts.update would
get much shorter.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On Wed, 16 Apr 2014, Martin Kosek wrote: In general I am not sure all authenticated users need access to all this info. Alexander ? SSSD needs to read some of this information for subdomains support. That would be at least host/*@REALM who needs to access it. Can you please list exactly which ones are needed ? SSSD subdomains support needs: - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs - ipaNTFlatName - ipaNTSecurityIdentifier - ipaNTTrustedDomainSID - cn Question is - is there any added value in hiding part of the trust information from authenticated users? I.e. attributes like ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this attribute anyway?), SID blacklists... Yes. Some of those attributes are needed as internal detail of ipasam -- part of how Samba stores this information taken from specific DCE RPC structures. If yes, we would need to split this permission in 2 and have one for authenticated users and one for Trust Adminitrators and Trust Readers. Yes. Authenticated users shouldn't get any access to those details: ipantsupportedencryptiontypes ipanttrustattributes ipanttrustauthincoming ipanttrustauthoutgoing Ok. I assume that cn=adtrust agents,cn=sysaccounts,SUFFIX system group should then have this permission assigned so that samba can operate the attributes. 'adtrust agents' and 'trust administrators' should have read, modify, delete, and search on cn=trusts. Right. We will probably want to turn most of ACIs in install/updates/60-trusts.update in managed permissions (i.e. defined in trust.py) and make adtrust agents and trust admins it's members. I agree. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH][RFC] 13 - Log pretty-printed request and response
Misnyovszki Adam wrote: Hi, this patch enables logging json dumps of request and response, using the --log-payload switch in ipa cli. RFC tag is to ensure that I handled the --log-payload switch correctly in ipa cli. Be careful, it only logs, so --log-payload without -v switch doesn't make the dump visible in command line, -v does! https://fedorahosted.org/freeipa/ticket/4233 Not a NACK but using -vvv makes this a much simpler operation as you can then just compare verbose = 3. This seems like a lot of work just to pretty-print some output. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On Wed, 2014-04-16 at 18:34 +0300, Alexander Bokovoy wrote: On Wed, 16 Apr 2014, Martin Kosek wrote: In general I am not sure all authenticated users need access to all this info. Alexander ? SSSD needs to read some of this information for subdomains support. That would be at least host/*@REALM who needs to access it. Can you please list exactly which ones are needed ? SSSD subdomains support needs: - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs - ipaNTFlatName - ipaNTSecurityIdentifier - ipaNTTrustedDomainSID - cn Question is - is there any added value in hiding part of the trust information from authenticated users? I.e. attributes like ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this attribute anyway?), SID blacklists... Yes. Some of those attributes are needed as internal detail of ipasam -- part of how Samba stores this information taken from specific DCE RPC structures. If yes, we would need to split this permission in 2 and have one for authenticated users and one for Trust Adminitrators and Trust Readers. Yes. Authenticated users shouldn't get any access to those details: ipantsupportedencryptiontypes ipanttrustattributes ipanttrustauthincoming ipanttrustauthoutgoing Ok. I assume that cn=adtrust agents,cn=sysaccounts,SUFFIX system group should then have this permission assigned so that samba can operate the attributes. 'adtrust agents' and 'trust administrators' should have read, modify, delete, and search on cn=trusts. Right. We will probably want to turn most of ACIs in install/updates/60-trusts.update in managed permissions (i.e. defined in trust.py) and make adtrust agents and trust admins it's members. I agree. +1 Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0528 Add managed read permission to automount
Martin Kosek wrote: On 04/16/2014 02:14 PM, Petr Viktorin wrote: A single permission granting anonymous read access covers automountlocation, automountmap, and automountkey. This works fine, I am just wondering about the ACI: 1) Simo, are you OK with one ACI covering all automount objects? I personally am, I cannot imagine a situation when somebody allows automount maps but not the automount keys. But on the other hand, we also have separate permissions for sudo commands, sudo command groups, sudo rules... With sudo you may want a different set of users deciding WHAT can be executed from WHO can execute it. I don't think automount needs that level of specificity. 2) Should we limit the ACI by an objectclass filter? I.e. (|(objectclass=automountmap)(objectclass=automount))? I think these are the only things living in that container so it may be overkill. I'm not against adding it if someone feels more strongly about it. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0528 Add managed read permission to automount
On Wed, 2014-04-16 at 11:59 -0400, Rob Crittenden wrote: Martin Kosek wrote: On 04/16/2014 02:14 PM, Petr Viktorin wrote: A single permission granting anonymous read access covers automountlocation, automountmap, and automountkey. This works fine, I am just wondering about the ACI: 1) Simo, are you OK with one ACI covering all automount objects? I personally am, I cannot imagine a situation when somebody allows automount maps but not the automount keys. But on the other hand, we also have separate permissions for sudo commands, sudo command groups, sudo rules... With sudo you may want a different set of users deciding WHAT can be executed from WHO can execute it. I don't think automount needs that level of specificity. 2) Should we limit the ACI by an objectclass filter? I.e. (|(objectclass=automountmap)(objectclass=automount))? I think these are the only things living in that container so it may be overkill. I'm not against adding it if someone feels more strongly about it. I think Rob summarized my own thought, and I think he has more authority than I have as he's been working on automount stuff more than I have. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On Wed, Apr 16, 2014 at 04:59:55PM +0300, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Simo Sorce wrote:
+'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo',
+'ipanttrustposixoffset',
'ipantsupportedencryptiontypes',
+'ipantsidblacklistincoming',
'ipantsidblacklistoutgoing',
+# ipaNTDomainAttrs:
+'ipantsecurityidentifier', 'ipantflatname',
'ipantdomainguid',
+'ipantfallbackprimarygroup',
+},
+},
+}
label = _('Trusts')
label_singular = _('Trust')
In general I am not sure all authenticated users need access to all this
info. Alexander ?
SSSD needs to read some of this information for subdomains support.
That would be at least host/*@REALM who needs to access it.
Can you please list exactly which ones are needed ?
SSSD subdomains support needs:
- objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs
- ipaNTFlatName
- ipaNTSecurityIdentifier
- ipaNTTrustedDomainSID
- cn
- objectclass ipaIDRange
- cn
- ipaBaseID
- ipaIDRangeSize
- ipaBaseRID
- ipaSecondaryBaseRID
iparangetype and ipanttrusteddomainsid are needed as well.
bye,
Sumit
Simo.
--
/ Alexander Bokovoy
___
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] Ipa-server-install Firewall Support
On 04/16/2014 08:39 AM, Martin Kosek wrote: On 04/16/2014 09:56 AM, Justin Brown wrote: ... L: This is interesting, and I have a couple of questions on how this should work. 1) Is there an actual use-case when a tool actually would want to check status of a port without correcting it? It seems to me that any sort of is_port_open() call that returned False would be immediately followed by open_port(). If that's the case, then why not just roll them into one operation? There won't be any firewall reload if no modifications take place, so there's no cost to combining them. We could also find a middle ground where there's only one method with a default parameter open_port(..., auto_add=True). I can imagine situations when we would want to see if a port is open in a firewall and then ask user if he wants to automatically open it. In such cases, 2 separate calls would be indeed helpful. 2) Will these tools be executed as root? To query NM and FirewallD, I have to connect to the system bus, which by default, won't allow access from other users without additional authorization. If non-privileged users need to query the firewall configuration, I'll need to look at the DBus policy more closely. In situations when we are about to manipulate ports, I think it is safe to assume we are operating under root account. I think you can have this assumption in your current code and do not deal with additional authorization at this point. We can think about this case when we need it. 3) Could you point me at a similar tool that has this check and modify behavior? There are many situations in FreeIPA interactive wizards where we have a pattern do_action = check_something() if do_action: do_something() For example, ipa-adtrust-install is checking if there are any users without SID assigned and if there are, it offers to run a task to add them. Martin +1 on all -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust
On 04/15/2014 05:13 AM, Sumit Bose wrote: Hi, I have started to write a design page for 'Migrating existing environments to Trust' http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust It shall cover https://fedorahosted.org/freeipa/ticket/3318 and https://fedorahosted.org/freeipa/ticket/3979 . I came across several questions which need answers so that more details can be added to the design. Besides that comments and suggestions are welcome as well. For your convenience I added the test below as well. bye, Sumit = Overview = This page illustrates how existing solutions which make AD users available to Linux hosts can be migrated to FreeIPA with Trusts. This includes migrations from the FreeIPA WinSync feature or environments where the AD users where correlated to NIS users. The common problem here is that some if not all attributes needed by a POSIX user or group must be overwritten or supplied by the IPA server. The link to the related AD object is preferably the SID but if it is not available on both sides the name of the object must be used. AD will keep the responsibility for authentication and provide the AD group-memberships of the object. = Use Cases = * Migration from the FreeIPA Sync solution to the FreeIPA Trust solution ** [https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/3318] * Migration/Consolidation of domains currently managed by other solutions, e.g. NIS ** [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] (contains some ideas about a solution) As I mentioned in the ticket not only that. Based on conversations with different potential consumers of the trust functionality the ability to use existing POSIX attributes and manage them in IPA while user accounts come from AD is a crucial next step. = Design = In Ticket [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] two aspects of a design are already explained. # Instead of just offering a single override option the introduction of views are suggested. A suitable client can ask for a specific view with override options different from the default override view. Yes. Questions: #* Will the default view always be applied? I think it makes sense to always apply it to get a consistent default behavior. If there is a reason for a client to get the unmodified data a special view called e.g. NO_OVERRIDE can be used. This is e.g. needed for the extdom plugin to be able to send the raw data to the IPA client so that SSSD can use different views on the client which might be needed for docker/container use cases. Sounds reasonable to have the default view and apply it always. If the view does not contain posix attributes for the specific user we should use dynamic mapping based on SIDs. #* Will views only be applied to users from other domains or to IPA users as well? Design goal will be to allow them to be applied to all users. Implementation goal will be to apply them to external users first. Or I should say we need to figure out the procedure: 1) Pre migration: AD with no POSIX, LDAP/NIS with POSIX for some/same users. 2) Past migration: AD with no POSIX, no duplicate accounts in IdM, POSIX attributes for AD users are migrated into a view. How we do it is the question but we need to have a path. May be it would require some kind of tool: ipa create-view --check This will go through all users in IPA and check them against available trusted domains and would report which users will be removed becuase they are found in a specific domain. ipa create-view --create --except=group list This will actually do the work but if there are special users that need to be processed in some special way admin might temporarily put them into a specific group and then exclude this group or groups from cleanup. Just a thought... #* Do we want stackable views? We want client oriented views. I.e. views should be attached to host groups. For the legacy clients there should be a way to expose a view as a separate base=DN so that one set of legacy clients can be pointed to one DN and another to another. If the host based views and DN based views do not have data for a specific user the data should be fetched from a global default view. I think we can use CoS for that in conjunction with the compat plugin but I would leave this to experts to decide. Bottom line: one global fallback view and then specific views for host groups and for legacy clients. I know I might be asking a lot ;-) #* Do we want to override everything or shall there be immutable attributes like e.g. the SID or the user name? I do not know why would overwrite the SID but I think that overwriting the user name would give us an interesting aliasing capability as a feature as a side effect. #* Shall we allow different UIDs/GIDs in different views? Yes. #* I
Re: [Freeipa-devel] [PATCH] 0528 Add managed read permission to automount
On 04/16/2014 06:15 PM, Simo Sorce wrote: On Wed, 2014-04-16 at 11:59 -0400, Rob Crittenden wrote: Martin Kosek wrote: On 04/16/2014 02:14 PM, Petr Viktorin wrote: A single permission granting anonymous read access covers automountlocation, automountmap, and automountkey. This works fine, I am just wondering about the ACI: 1) Simo, are you OK with one ACI covering all automount objects? I personally am, I cannot imagine a situation when somebody allows automount maps but not the automount keys. But on the other hand, we also have separate permissions for sudo commands, sudo command groups, sudo rules... With sudo you may want a different set of users deciding WHAT can be executed from WHO can execute it. I don't think automount needs that level of specificity. 2) Should we limit the ACI by an objectclass filter? I.e. (|(objectclass=automountmap)(objectclass=automount))? I think these are the only things living in that container so it may be overkill. I'm not against adding it if someone feels more strongly about it. I think Rob summarized my own thought, and I think he has more authority than I have as he's been working on automount stuff more than I have. Simo. Thanks for discussion. In that case, the ACI is good as is. ACK. Pushed to master: adde918f38a7df8f72e5293d1d0c5a5637b7e5a8 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
