Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts
On 04/10/2014 05:29 PM, Petr Viktorin wrote: On 04/10/2014 03:04 PM, Martin Kosek wrote: On 04/10/2014 02:52 PM, Simo Sorce wrote: On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: On 04/09/2014 12:25 PM, Martin Kosek wrote: On 04/03/2014 12:09 PM, Petr Viktorin wrote: Hello, This adds read permissions to read hosts. Read access is given to all authenticated users. For reading host membership info, there is a separate permission that also defaults to all authenticated users. The userPassword attribute is not included for obvious reasons. 1) We decided to show hosts only to authenticated users by default. I am just thinking - should some portion of hosts be readable just like groups and users are? For example at least the host core defined by nsHost objectlass? objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) Are application supposed to be able to anonymously read that information? I'm not sure. Simo? Good question, probably not by default, we offer DNS and do not recommend people to rely on exposed host maps. Question is if should have a separate permission like System: Read Host Core Attributes, System: Read Host, System: Read Host Membership or we are fine with just System: Read Host, System: Read Host Membership. If we do not expect people and programs to often read the list of host or the basic host information anonymously, I would stick with the latter. Let's do that then. It's easy enough to add a custom permission. 2) Do we want to count enrolledBy and managedBy attribute to System: Read Host Membership permission or should it be included in the Read Hosts permission? If we want to stick with previous behavior, we would want to have only memberOf listed as this is how our original member handling ACI looks like: install/share/default-aci.ldif:aci: (targetattr = memberOf || memberHost || memberUser)(version 3.0; acl No anonymous access to member information; deny (read,search,compare) userdn != ldap:///all;; What was the reasoning behind enrolledBy and managedBy? I got it from the notes from devconf; I don't think there was much discussion. I have no recollection :( There was no discussion about these particular attributes. I added then to Membership permission because they were DN-ish, but when I think more about it, it does not seem as a membership in the sense of the ACI above. I would personally only keep member/memberOf in the Membership attributes. Moved to Read Host. 3) I could not functionally test if e.g. clients and replicas still enroll as we do not have an ACI for krbtpolicy/krbRealmContainer yet and ipa-client-install searches for it. Speaking of which, we will need to have an ACI for reading a portion of krbRealmContainer anonymously to enable IPA client autodiscovery (cn+objectclass should be sufficient). Sad we ended up depending on this, I would have preferred to not depend on keeping this around if we ever want to change something. Yeah... But we should be OK with exposing just the CN which is not really a secret as we know what is the realm name... Martin The basis looks good now. However, when I was checking host's objectclass and attributes we allow, I saw many attributes not listed in our DevConf meeting minutes, but which are now missing in the entry when I read it as authenticated used. krbPrincipalAux attributes like krbCanonicalName, krbExtraData, krbLastAdminUnlock, krbLastFailedAuth... We may want to list them all, except the ones we chose to now show, like krbPrincipalKey :) I would welcome Simo's recommendation in this place. krbTicketPolicyAux attributes like krbMaxRenewableAge Objectclasses for reference: objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF ailedCount $ krbExtraData $ krbLastAdminUnlock ) ) objectClasses: ( 2.16.840.1.113719.1.301.6.16.1 NAME 'krbTicketPolicyAux' AUXI LIARY MAY ( krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge ) ) Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0516 Add managed read permissions to realmdomains
On 04/10/2014 03:55 PM, Petr Viktorin wrote: Read access is given to all authenticated users. Works for me, ACK. Pushed to master, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to RBAC objects
On 04/10/2014 05:03 PM, Petr Viktorin wrote: On 04/10/2014 03:20 PM, Martin Kosek wrote: On 04/10/2014 03:10 PM, Petr Viktorin wrote: On 04/10/2014 03:07 PM, Martin Kosek wrote: On 04/10/2014 03:02 PM, Petr Viktorin wrote: On 04/10/2014 02:58 PM, Martin Kosek wrote: On 04/10/2014 01:46 PM, Petr Viktorin wrote: On 04/09/2014 05:17 PM, Martin Kosek wrote: On 04/09/2014 04:54 PM, Petr Viktorin wrote: The meta-permissions. :-) Read access is given to all authenticated users. Reading membership info (i.e. privileges) is split into a separate permission. Another permission is added that allows read access to all ACIs. If we don't want to open that up for everyone, I could limit this to only ACIs containing permission:. (Since old-style permissions store their information in ACIs, their ACIs need to be readable.) If I read the notes from our DevConf discussion correctly, there are some inconsistencies: 1) We decided to not do special membership permission for permission/privilege/role permissions. 2) We decided to give read access to permissions, privileges and roles only to member of a certain privilege. Is there any reason to not do that? IMO, regular users do not need to be able to read the permission/privilege/role configuration of a FreeIPA installation to use it for IdM. Martin Updated. I plan to add all the RBAC-related read permissions to a single privilege, RBAC Readers. Or do we want more granularity by default? Requires my patch 0514. I was looking at the granularity we currently have with privilege and it is mostly per FreeIPA function (Sudo Administrator or DNS Administrator), not per IPA object (Sudo Command Administrator, Sudo Rule Administrator). I would thus follow the same principle with RBAC and create RBAC Administrator privilege which will cover read permissions for... permissions... privileges and roles. In time, we will also add new write privileges there as they are currently missing. To sum it up, the patch works, I would just change the name of the privilege and not focus it just on reading. So to confirm, we want one privilege to cover both reading and writing? IMO, yes. Should I add new read permissions to existing Administrator privileges only, instead of creating new Reader permissions? I don't think so. The read permission we have been adding so far were targetted on anonymous/all binds, thus according to our design, they cannot be added to privilege anyway. But if someone wants to restrict an object, he is free to change the permission bind type to group based and assign it to a privilege. In our case, I would assign read permission to privilege only if we decided to make them group based, like RBAC or krbtpolicy ones. Right, that makes sense. I'm asking about not having separate read privileges when the permissions are group based. Based on Simo's other mail we should have separate Read privileges. Also IMO the read permissions should then be added both to the Reader and Administrator privileges, since it doesn't make sense to be able to write but not read. Ah, I understand the question now. This assumes that people may often want to allow a certain group of people to read RBAC or to read ticket policy. I would assume that a more frequent usage would be that administrator would allow all authenticated users read an object (which makes Read group redundant). But I am not insisting, I am open to both approaches. I think it's reasonable to give read (but not write) access to lower-level admins only. Here is an updated patch. I've added read for privileges and roles too, so the 'RBAC Readers' privilege should be complete. Thanks, works for me. ACK. Pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0515 Add managed read permission for SELinux user map
On 04/10/2014 03:30 PM, Petr Viktorin wrote: Read access is given to all authenticated users. ACK, works fine. Pushed to master: 3db9ce320422a6cc57e1767a1e0cbf06d950a67e Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0517 test_realmdomains_plugin: Add default ACI to expected output
On 04/10/2014 03:55 PM, Petr Viktorin wrote: Subject: [PATCH] 0516 Add managed read permissions to realmdomains Read access is given to all authenticated users. Jenkins tells me this breaks tests. Since realmdomains ACIs are set on a single entry, not a container, realmdomains_show --all will include the ACI in the output. As it should, since we're asking for all LDAP attributes. Test fix attached. -- Petr³ From cb3ef663fe02995b732b24dada901c7d3ed8cb13 Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Fri, 11 Apr 2014 12:32:08 +0200 Subject: [PATCH] test_realmdomains_plugin: Add default ACI to expected output Since realmdomains is only one entry, _show with --all will return the ACI on it. Add it to expected output. --- ipatests/test_xmlrpc/test_realmdomains_plugin.py | 9 + 1 file changed, 9 insertions(+) diff --git a/ipatests/test_xmlrpc/test_realmdomains_plugin.py b/ipatests/test_xmlrpc/test_realmdomains_plugin.py index 8abb53e482f206249e029821468b35a47b9ce59a..1d4dda3d2ef80f2bed0bb159486a4f2cdcac8d3d 100644 --- a/ipatests/test_xmlrpc/test_realmdomains_plugin.py +++ b/ipatests/test_xmlrpc/test_realmdomains_plugin.py @@ -64,6 +64,15 @@ class test_realmdomains(Declarative): associateddomain=[our_domain], cn=[cn], objectclass=objectclasses.realmdomains, +aci=[ +u'(targetattr = associateddomain || cn || ' +u'objectclass)' +u'(targetfilter = (objectclass=domainrelatedobject))' +u'(version 3.0;acl ' +u'permission:System: Read Realm Domains;' +u'allow (read,compare,search) ' +u'userdn = ldap:///all;;)' +], ), ), ), -- 1.9.0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Do not ask for memberindirect when updating managed permissions
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?
--
Petr³
From 2449c1e9a589001188fe4085c3d2dd219bdbc4e8 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Fri, 11 Apr 2014 12:09:32 +0200
Subject: [PATCH] Do not ask for memberindirect when updating managed
permissions
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.
---
ipaserver/install/plugins/update_managed_permissions.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py
index efd87d0d197e463dc07efc8ae7fb9a88c87642a6..3bba1f06e75fc2a0e57bce682827992e31f27708 100644
--- a/ipaserver/install/plugins/update_managed_permissions.py
+++ b/ipaserver/install/plugins/update_managed_permissions.py
@@ -133,7 +133,8 @@ def update_permission(self, ldap, obj, name, template,
dn = self.api.Object[permission].get_dn(name)
try:
-attrs_list = self.api.Object[permission].default_attributes
+attrs_list = list(self.api.Object[permission].default_attributes)
+attrs_list.remove('memberindirect')
entry = ldap.get_entry(dn, attrs_list)
is_new = False
except errors.NotFound:
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0519 Add managed read permissions to pwpolicy and cosentry
Read access is given as a new privilege, 'Password Policy Readers', and
also to the existing privilege 'Password Policy Administrator'.
--
Petr³
From c61532cd5bbce02f073a94fdceff8169c4d4b52d 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 pwpolicy and cosentry
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
install/updates/40-delegation.update | 7 +++
ipalib/plugins/pwpolicy.py | 34 ++
2 files changed, 41 insertions(+)
diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update
index e90819a5117afae5f65a24cb7b099f7e160dfa17..27e605789ba152ac61796217ca12a603958931c1 100644
--- a/install/updates/40-delegation.update
+++ b/install/updates/40-delegation.update
@@ -401,3 +401,10 @@ dn: cn=RBAC Readers,cn=privileges,cn=pbac,$SUFFIX
default:objectClass: top
default:cn: RBAC Readers
default:description: Read roles, privileges, permissions and ACIs
+
+dn: cn=Password Policy Readers,cn=privileges,cn=pbac,$SUFFIX
+default:objectClass: nestedgroup
+default:objectClass: groupofnames
+default:objectClass: top
+default:cn: Password Policy Readers
+default:description: Read password policies
diff --git a/ipalib/plugins/pwpolicy.py b/ipalib/plugins/pwpolicy.py
index 46e839a70edf9d2bd3b8baba66ced7e9ce1b8e19..1d546ea75be61f9bf5b0ab2f571b7d98c9cc2ac1 100644
--- a/ipalib/plugins/pwpolicy.py
+++ b/ipalib/plugins/pwpolicy.py
@@ -78,7 +78,22 @@ class cosentry(LDAPObject):
container_dn = DN(('cn', 'costemplates'), api.env.container_accounts)
object_class = ['top', 'costemplate', 'extensibleobject', 'krbcontainer']
+permission_filter_objectclasses = ['costemplate']
default_attributes = ['cn', 'cospriority', 'krbpwdpolicyreference']
+managed_permissions = {
+'System: Read Group Password Policy costemplate': {
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'permission',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'cn', 'cospriority', 'krbpwdpolicyreference', 'objectclass',
+},
+'default_privileges': {
+'Password Policy Readers',
+'Password Policy Administrator',
+},
+},
+}
takes_params = (
Str('cn', primary_key=True),
@@ -180,12 +195,31 @@ class pwpolicy(LDAPObject):
object_name = _('password policy')
object_name_plural = _('password policies')
object_class = ['top', 'nscontainer', 'krbpwdpolicy']
+permission_filter_objectclasses = ['krbpwdpolicy']
default_attributes = [
'cn', 'cospriority', 'krbmaxpwdlife', 'krbminpwdlife',
'krbpwdhistorylength', 'krbpwdmindiffchars', 'krbpwdminlength',
'krbpwdmaxfailure', 'krbpwdfailurecountinterval',
'krbpwdlockoutduration',
]
+managed_permissions = {
+'System: Read Group Password Policy': {
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'permission',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'cn', 'cospriority', 'krbmaxpwdlife', 'krbminpwdlife',
+'krbpwdfailurecountinterval', 'krbpwdhistorylength',
+'krbpwdlockoutduration', 'krbpwdmaxfailure',
+'krbpwdmindiffchars', 'krbpwdminlength', 'objectclass',
+},
+'default_privileges': {
+'Password Policy Readers',
+'Password Policy Administrator',
+},
+},
+}
+
MIN_KRB5KDC_WITH_LOCKOUT = 1.8
has_lockout = False
lockout_params = ()
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 569-583 New Login Screen
On Fri, 28 Mar 2014 14:04:13 +0100 Petr Vobornik pvobo...@redhat.com wrote: Attached patches replace IPA.unauthorized dialog with new Login Screen. To make it happen, a support for standalone facets had to be developed because current framework was limited by facets dependent on entities and a container with menu. This new feature was already used for Load facet which is part of this patchset and also will be a basis for API browser and OTP sync page. Patches should fix these tickets: https://fedorahosted.org/freeipa/ticket/3903 https://fedorahosted.org/freeipa/ticket/4017 Depends on patches #565-#568. [PATCH] webui: facet container -- A widget which servers as container for facets. FacetContainer is a base class. App is specialization. Doing this abstraction will allow us to implement various facet containers. [PATCH] webui: FormMixin a mixin used for fields validation. Basically implements a logic which is already in details facet and dialog. Now this logic can be used in any component. The long term goal is to replace the logic in details facet and dialog with this mixin. [PATCH] webui: ContainerMixin - A mixin which implements widget storing logic. Similar logic is already implemented in details facet and dialog. Long term goal is to replace that with this one. Separating the logic into mixin makes it usable in other components. [PATCH] webui: standalone facet --- `facet.Facet` is a new base class for facets. It doesn't have any dependencies on entities so it's usable for general purpose facets, e.g., future API browser, load facet or login facet. [PATCH] webui: activity widget -- A widget for showing ongoing activity. Displays a text with changing dots. It listens to `network-activity-start` and `network-activity-end` topics. [PATCH] webui: publish network activity topics -- Network activity is now published through global topics. It allows other components like activity_widget to listen to them. [PATCH] webui: load page Load page is a simple facet which is displayed up to 'runtime' phase. On application start it tells the user that there is ongoing activity. [PATCH] webui: validation summary widget A widget which aggregates warnings and errors and shows them on one place. [PATCH] webui: login screen widget -- Reimplementation of unauthorized dialog into separate widget. It uses RCUE design. New features compared to unauthorized dialog: - reflects auth methods from `auth` module - validation summary - differentiates Kerberos auth failure with session expiration - Caps Lock warning - form based method doesn't allow password only submission https://fedorahosted.org/freeipa/ticket/4017 https://fedorahosted.org/freeipa/ticket/3903 [PATCH] webui: login page - A facet with login sreen widget. [PATCH] webui: authentication module General purpose authentication interface and state. See doc of 'freeipa/auth' module. [PATCH] webui: use asynchronous call for authentication Change `IPA.login_password` and `IPA.get_credentials` to use async AJAX and to return promise instead of blocking the code. IPA.get_credentials is still partially blocking because of negotiate process. We can't do anything about that. It allows activity indicators to do their job. [PATCH] webui: fix combobox styles to work with selenium testing [PATCH] webui-ci: adapt to new login screen [PATCH] webui: remove IPA.unauthorized_dialog Hi, - Attached patch fixes weird combobox behaviour - opens automatically on facet load - When trying to log in with password only(username field is empty), there is an error message Authentication with Kerberos failed, which is not the desired behaviour. It should sign that the username field is invalid. - When trying to log in with kerberos credentials, and the realm of the krb ticket is not the same as the realm of freeipa(eg freeipa realm is IPA.TEST.COM, and the ticket's is TEST.COM), firefox goes into an endless cycle calling the kerberos auth url. Currently it seems to me as a browser issue. Anyways, with correct krb ticket, authentication works fine. Although, unit tests ran, integration tests ran as expected, and browsing through the code manually was ok for me, so if that validation issue is corrected, than it will be an ACK. Thanks: Adam From 633b162c414ecc8c156d90d5c4c1860b1e418288 Mon Sep 17 00:00:00 2001 From: Adam Misnyovszki amisn...@redhat.com Date: Fri, 4 Apr 2014 16:47:15 +0200 Subject: [PATCH] combobox widget fix this patch fixes the combobox widget, so it doesn't open on
Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts
On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote: On 04/10/2014 05:29 PM, Petr Viktorin wrote: On 04/10/2014 03:04 PM, Martin Kosek wrote: On 04/10/2014 02:52 PM, Simo Sorce wrote: On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: On 04/09/2014 12:25 PM, Martin Kosek wrote: On 04/03/2014 12:09 PM, Petr Viktorin wrote: Hello, This adds read permissions to read hosts. Read access is given to all authenticated users. For reading host membership info, there is a separate permission that also defaults to all authenticated users. The userPassword attribute is not included for obvious reasons. 1) We decided to show hosts only to authenticated users by default. I am just thinking - should some portion of hosts be readable just like groups and users are? For example at least the host core defined by nsHost objectlass? objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) Are application supposed to be able to anonymously read that information? I'm not sure. Simo? Good question, probably not by default, we offer DNS and do not recommend people to rely on exposed host maps. Question is if should have a separate permission like System: Read Host Core Attributes, System: Read Host, System: Read Host Membership or we are fine with just System: Read Host, System: Read Host Membership. If we do not expect people and programs to often read the list of host or the basic host information anonymously, I would stick with the latter. Let's do that then. It's easy enough to add a custom permission. 2) Do we want to count enrolledBy and managedBy attribute to System: Read Host Membership permission or should it be included in the Read Hosts permission? If we want to stick with previous behavior, we would want to have only memberOf listed as this is how our original member handling ACI looks like: install/share/default-aci.ldif:aci: (targetattr = memberOf || memberHost || memberUser)(version 3.0; acl No anonymous access to member information; deny (read,search,compare) userdn != ldap:///all;; What was the reasoning behind enrolledBy and managedBy? I got it from the notes from devconf; I don't think there was much discussion. I have no recollection :( There was no discussion about these particular attributes. I added then to Membership permission because they were DN-ish, but when I think more about it, it does not seem as a membership in the sense of the ACI above. I would personally only keep member/memberOf in the Membership attributes. Moved to Read Host. 3) I could not functionally test if e.g. clients and replicas still enroll as we do not have an ACI for krbtpolicy/krbRealmContainer yet and ipa-client-install searches for it. Speaking of which, we will need to have an ACI for reading a portion of krbRealmContainer anonymously to enable IPA client autodiscovery (cn+objectclass should be sufficient). Sad we ended up depending on this, I would have preferred to not depend on keeping this around if we ever want to change something. Yeah... But we should be OK with exposing just the CN which is not really a secret as we know what is the realm name... Martin The basis looks good now. However, when I was checking host's objectclass and attributes we allow, I saw many attributes not listed in our DevConf meeting minutes, but which are now missing in the entry when I read it as authenticated used. As an admin, or as a regular user ? krbPrincipalAux attributes like krbCanonicalName, krbExtraData, krbLastAdminUnlock, krbLastFailedAuth... We may want to list them all, except the ones we chose to now show, like krbPrincipalKey :) I would welcome Simo's recommendation in this place. I do not think we necessarily need to expose most of them to regular users (which include keytab bearing services) by default. krbTicketPolicyAux attributes like krbMaxRenewableAge Objectclasses for reference: objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF ailedCount $ krbExtraData $ krbLastAdminUnlock ) ) Of these we may want to show krbPrincipalName, krbCanonicalName, krbPrincipalAliases by default. I am uncertain about krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange, but they may be needed for clients like SSSD to do proper checking and for power users to figure out themselves when they
Re: [Freeipa-devel] [PATCH] 0519 Add managed read permissions to pwpolicy and cosentry
On Fri, 2014-04-11 at 14:26 +0200, Petr Viktorin wrote: Read access is given as a new privilege, 'Password Policy Readers', and also to the existing privilege 'Password Policy Administrator'. LGTM 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] 0506 Default read ACIs for hosts
On 04/11/2014 02:36 PM, Simo Sorce wrote: On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote: On 04/10/2014 05:29 PM, Petr Viktorin wrote: On 04/10/2014 03:04 PM, Martin Kosek wrote: On 04/10/2014 02:52 PM, Simo Sorce wrote: On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: On 04/09/2014 12:25 PM, Martin Kosek wrote: On 04/03/2014 12:09 PM, Petr Viktorin wrote: Hello, This adds read permissions to read hosts. Read access is given to all authenticated users. For reading host membership info, there is a separate permission that also defaults to all authenticated users. The userPassword attribute is not included for obvious reasons. 1) We decided to show hosts only to authenticated users by default. I am just thinking - should some portion of hosts be readable just like groups and users are? For example at least the host core defined by nsHost objectlass? objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) Are application supposed to be able to anonymously read that information? I'm not sure. Simo? Good question, probably not by default, we offer DNS and do not recommend people to rely on exposed host maps. Question is if should have a separate permission like System: Read Host Core Attributes, System: Read Host, System: Read Host Membership or we are fine with just System: Read Host, System: Read Host Membership. If we do not expect people and programs to often read the list of host or the basic host information anonymously, I would stick with the latter. Let's do that then. It's easy enough to add a custom permission. 2) Do we want to count enrolledBy and managedBy attribute to System: Read Host Membership permission or should it be included in the Read Hosts permission? If we want to stick with previous behavior, we would want to have only memberOf listed as this is how our original member handling ACI looks like: install/share/default-aci.ldif:aci: (targetattr = memberOf || memberHost || memberUser)(version 3.0; acl No anonymous access to member information; deny (read,search,compare) userdn != ldap:///all;; What was the reasoning behind enrolledBy and managedBy? I got it from the notes from devconf; I don't think there was much discussion. I have no recollection :( There was no discussion about these particular attributes. I added then to Membership permission because they were DN-ish, but when I think more about it, it does not seem as a membership in the sense of the ACI above. I would personally only keep member/memberOf in the Membership attributes. Moved to Read Host. 3) I could not functionally test if e.g. clients and replicas still enroll as we do not have an ACI for krbtpolicy/krbRealmContainer yet and ipa-client-install searches for it. Speaking of which, we will need to have an ACI for reading a portion of krbRealmContainer anonymously to enable IPA client autodiscovery (cn+objectclass should be sufficient). Sad we ended up depending on this, I would have preferred to not depend on keeping this around if we ever want to change something. Yeah... But we should be OK with exposing just the CN which is not really a secret as we know what is the realm name... Martin The basis looks good now. However, when I was checking host's objectclass and attributes we allow, I saw many attributes not listed in our DevConf meeting minutes, but which are now missing in the entry when I read it as authenticated used. As an admin, or as a regular user ? krbPrincipalAux attributes like krbCanonicalName, krbExtraData, krbLastAdminUnlock, krbLastFailedAuth... We may want to list them all, except the ones we chose to now show, like krbPrincipalKey :) I would welcome Simo's recommendation in this place. I do not think we necessarily need to expose most of them to regular users (which include keytab bearing services) by default. krbTicketPolicyAux attributes like krbMaxRenewableAge Objectclasses for reference: objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF ailedCount $ krbExtraData $ krbLastAdminUnlock ) ) Of these we may want to show krbPrincipalName, krbCanonicalName, krbPrincipalAliases by default. Added. I am uncertain about krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange, but they may be needed for clients like SSSD to do proper checking and for power users to figure out themselves when they need to change passwords or ask for an account validity extension etc.. Let's show them then, to make their lives
