Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On 04/16/2014 06:56 PM, Sumit Bose wrote: On Wed, Apr 16, 2014 at 04:59:55PM +0300, Alexander Bokovoy wrote: On Wed, 16 Apr 2014, Simo Sorce wrote: ... Can you please list exactly which ones are needed ? ... - objectclass ipaIDRange - cn - ipaBaseID - ipaIDRangeSize - ipaBaseRID - ipaSecondaryBaseRID iparangetype and ipanttrusteddomainsid are needed as well. bye, Sumit Thanks. But in case of ID Ranges we are safe as we exposed all ID range attributes to all authenticated users (hosts). Trust objects are different, we plan to have at least 2 permissions so that only needed attributes are exposed. Martin ___ 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:58 PM, Martin Kosek wrote: 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 Thanks, pushed to master: 81b0e7466d739a61b16c0e79c660a9f85d073c8c -- Petr³ ___ 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 Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: 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. Thank you for your feedback, it was very helpful but I'm afraid it might also caused some new questions. = 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. Quite some time ago we have decided to not mix algorithmic mapping and manually managed POSIX IDs. E.g. think about the case where a view with POSIX ID was added for an existing user which already has an algorithmic ID assigned on some clients. I think the admin has to decide what he wants. Below you mentioned a migration use case where old users should keep their IDs but new users will get algorithmically generated ones. I think this is bad practice and technically is it next to impossible without additional admin effort to decide if a given AD user is an old or a new user. The admin either has to add special flags/attributes to the old AD user objects or we have to keep an immutable list of old users in IPA. Please note that this has to be done for groups as well. Imo it would be easier and safer for the admin to either do a full migration to algorithmically mapped IDs or manage all POSIX IDs manually on the IPA side. Additionally I think that in your use case there might be even the need to manually manage POSIX IDs even for new user. E.g. in the case where a larger amount of new users is added to AD which where managed by a completely independent system before. #* 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. Why, what is the use case to override attribute of IPA users which cannot be solved by adding other attributes with the needed values to the IPA user object directly? 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
Re: [Freeipa-devel] [PATCH] 0525 Add managed read permissions to automember
On 04/16/2014 04:35 PM, Martin Kosek wrote:
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.
Rebased to current master.
--
Petr³
From 12c06f859140bb5820c326207001e45f35c938e4 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 automember
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
install/updates/40-delegation.update | 7 +++
ipalib/plugins/automember.py | 29 +
2 files changed, 36 insertions(+)
diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update
index 6ab849bf86d129ef93472e970705b117147f0818..69061ca3df0cde8f66816e2f2f09aa15405a369e 100644
--- a/install/updates/40-delegation.update
+++ b/install/updates/40-delegation.update
@@ -415,3 +415,10 @@ dn: cn=Kerberos Ticket Policy Readers,cn=privileges,cn=pbac,$SUFFIX
default:objectClass: top
default:cn: Kerberos Ticket Policy Readers
default:description: Read global and per-user Kerberos ticket policy
+
+dn: cn=Automember Readers,cn=privileges,cn=pbac,$SUFFIX
+default:objectClass: nestedgroup
+default:objectClass: groupofnames
+default:objectClass: top
+default:cn: Automember Readers
+default:description: Read Automember definitions
diff --git a/ipalib/plugins/automember.py b/ipalib/plugins/automember.py
index 4b3f6f06f80ca8d20245a784ac2ba9a07c17a3e9..dad35d45850e56e90ea5f6a30769badec6941119 100644
--- a/ipalib/plugins/automember.py
+++ b/ipalib/plugins/automember.py
@@ -183,10 +183,39 @@ class automember(LDAPObject):
object_name = 'Automember rule'
object_name_plural = 'Automember rules'
object_class = ['top', 'automemberregexrule']
+permission_filter_objectclasses = ['automemberregexrule']
default_attributes = [
'automemberinclusiveregex', 'automemberexclusiveregex',
'cn', 'automembertargetgroup', 'description', 'automemberdefaultgroup'
]
+managed_permissions = {
+'System: Read Automember Definitions': {
+'non_object': True,
+'ipapermlocation': DN(container_dn, api.env.basedn),
+'ipapermtargetfilter': {'(objectclass=automemberdefinition)'},
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'permission',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'objectclass', 'cn', 'automemberscope', 'automemberfilter',
+'automembergroupingattr', 'automemberdefaultgroup',
+'automemberdisabled',
+},
+'default_privileges': {'Automember Readers',
+ 'Automember Task Administrator'},
+},
+'System: Read Automember Rules': {
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'permission',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'cn', 'objectclass', 'automembertargetgroup', 'description',
+'automemberexclusiveregex', 'automemberinclusiveregex',
+},
+'default_privileges': {'Automember Readers',
+ 'Automember Task Administrator'},
+},
+}
label = _('Auto Membership Rule')
--
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 04/16/2014 03:04 PM, Simo Sorce wrote: 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. Alright. I've reserved 2.16.840.1.113730.3.8.12.23 for a new ipaVirtualOperation objectclass. Let me know if I should use a different one. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Ipatests fixes
On 04/09/2014 01:33 PM, Petr Viktorin wrote:
On 04/09/2014 12:07 PM, Tomas Babej wrote:
Hi,
the following batch deals with the following:
* cleans up apache's semaphores prior to installing IPA (CA install can
get stuck when IPA is reinstalled many times)
What happens if Apache is running for some reason? Should we also stop
it before deleting the semaphores?
Agreed, if for any reason apache is running, we should stop it
beforehand. Fixed.
* allows to pass extra arguments to install_client task
Please avoid mutable argument defaults; use `extra_args=()` and then
`list(extra_args)`
Fixed.
* uses trailing dot in the hostname as fqdn which should not be
overridden by domain name
ACK.
* fixes incorrect assert for UIDs/GIDs in legacy client tests
ACK, this fixes a lot of failures (though not all of them yet).
Updated patches attached.
--
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From b066d30c5d34665ecc308edf4d53b60d012a4d1a Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Mon, 7 Apr 2014 12:40:52 +0200
Subject: [PATCH] ipatests: Fix apache semaphores prior to installing IPA
server
---
ipatests/test_integration/tasks.py | 14 ++
1 file changed, 14 insertions(+)
diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py
index d03ee6021fb34f8292814b23ea4e8fdd4606a90b..7f738e3d02fda6254502acb5eb3b3bbafdec3671 100644
--- a/ipatests/test_integration/tasks.py
+++ b/ipatests/test_integration/tasks.py
@@ -111,6 +111,18 @@ def fix_resolv_conf(host):
host.put_file_contents('/etc/resolv.conf', contents)
+def fix_apache_semaphores(master):
+systemd_available = master.transport.file_exists('/bin/systemctl')
+
+if systemd_available:
+master.run_command(['systemctl', 'stop', 'httpd'], raiseonerr=False)
+else:
+master.run_command(['/sbin/service', 'httpd', 'stop'], raiseonerr=False)
+
+master.run_command('for line in `ipcs -s | grep apache | cut -d -f 2`; '
+ 'do ipcrm -s $line; done', raiseonerr=False)
+
+
def unapply_fixes(host):
restore_files(host)
restore_hostname(host)
@@ -179,6 +191,7 @@ def install_master(host):
host.collect_log('/var/log/dirsrv/slapd-%s/access' % inst)
apply_common_fixes(host)
+fix_apache_semaphores(host)
host.run_command(['ipa-server-install', '-U',
'-r', host.domain.name,
@@ -197,6 +210,7 @@ def install_replica(master, replica, setup_ca=True):
replica.collect_log('/var/log/ipareplica-conncheck.log')
apply_common_fixes(replica)
+fix_apache_semaphores(replica)
master.run_command(['ipa-replica-prepare',
'-p', replica.config.dirman_password,
--
1.8.5.3
From 45352650c97b182354c00837b3d7de4bf0e0ad1c Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Mon, 7 Apr 2014 13:36:10 +0200
Subject: [PATCH] ipatests: tasks: Accept extra arguments when installing
client
---
ipatests/test_integration/tasks.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py
index 7f738e3d02fda6254502acb5eb3b3bbafdec3671..2334e254e7ddd00beeb83d8a317b5db12c06a29e 100644
--- a/ipatests/test_integration/tasks.py
+++ b/ipatests/test_integration/tasks.py
@@ -236,7 +236,7 @@ def install_replica(master, replica, setup_ca=True):
kinit_admin(replica)
-def install_client(master, client):
+def install_client(master, client, extra_args=()):
client.collect_log('/var/log/ipaclient-install.log')
apply_common_fixes(client)
@@ -246,7 +246,8 @@ def install_client(master, client):
'--realm', client.domain.realm,
'-p', client.config.admin_name,
'-w', client.config.admin_password,
-'--server', master.hostname])
+'--server', master.hostname]
++ list(extra_args))
kinit_admin(client)
--
1.8.5.3
From 3ffa1732b77484612282d8e1598317f172221ff1 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Mon, 7 Apr 2014 21:37:09 +0200
Subject: [PATCH] ipatests: Allow using FQDN with trailing dot as final
hostname
When creating a BaseHost instance, the machine's hostname was
reconfigured to have the same shortname prepended the domain name
of the domain where it was defined.
However, it makes sense in certain use cases to define hosts
that have hostnames other than belonging directly in the domain
they were defined in.
Treat input hostnames with trailing dots as static FQDNs that
will not be changed by the name of the domain they were defined in.
---
ipatests/test_integration/host.py | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ipatests/test_integration/host.py b/ipatests/test_integration/host.py
index
Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust
On Thu, 17 Apr 2014, Sumit Bose wrote: On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: 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. Thank you for your feedback, it was very helpful but I'm afraid it might also caused some new questions. = 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. Quite some time ago we have decided to not mix algorithmic mapping and manually managed POSIX IDs. E.g. think about the case where a view with POSIX ID was added for an existing user which already has an algorithmic ID assigned on some clients. I think the admin has to decide what he wants. Below you mentioned a migration use case where old users should keep their IDs but new users will get algorithmically generated ones. I think this is bad practice and technically is it next to impossible without additional admin effort to decide if a given AD user is an old or a new user. The admin either has to add special flags/attributes to the old AD user objects or we have to keep an immutable list of old users in IPA. Please note that this has to be done for groups as well. Imo it would be easier and safer for the admin to either do a full migration to algorithmically mapped IDs or manage all POSIX IDs manually on the IPA side. Additionally I think that in your use case there might be even the need to manually manage POSIX IDs even for new user. E.g. in the case where a larger amount of new users is added to AD which where managed by a completely independent system before. For this case admins could force manual POSIX mapping even if there are no POSIX attributes in AD, then use views to supply proper IDs to those users that require them. #* 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. Why, what is the use case to override attribute of IPA users which cannot be solved by adding other attributes with the needed values to the IPA user object directly? I agree, why should we introduce a new level of shadowing for IPA users given that the only tool that would accept these views would be a new SSSD version. I could understand that shadowing to IPA users on selected old clients
Re: [Freeipa-devel] [PATCH] 0525 Add managed read permissions to automember
On 04/17/2014 12:03 PM, Petr Viktorin wrote: On 04/16/2014 04:35 PM, Martin Kosek wrote: 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. Rebased to current master. This is ok, ACK. Pushed to master: 1e46c0a36159c990e083f771de2c0a18ecdbc42e Martin ___ 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: 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. OK [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? I thought it would be helpful to have a distinction between what needs anonymous read, and what's optional. I can move individual attributes, of course. My proposal would be to have a permission Read User Information for all attributes above. This way a paranoid admin would need to go through the attributes one by one to decide what needs to stay anonymous and what doesn't. Having two permissions makes this easier to tune. But of course I can merge them. Kerberos/login-related (all authenticated): [krbPrincipalAux] krbPrincipalName, krbCanonicalName, krbPrincipalAliases, krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange [+] nsAccountLock Ok. So permission Read User Kerberos Attributes? OK Kerberos-related (user admins only): [krbPrincipalAux] krbLastSuccessfulAuth, krbLastFailedAuth, krbLastPwdChange So permission Read User Kerberos Login Attributes? OK 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. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements
Hi,
This set of patches deals with bugs and extensions of ipa_range_check
plugin.
See commit messages for details.
Parts of: https://fedorahosted.org/freeipa/ticket/4137
--
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 43cd26a0a42c3b18e4dbb5c6ed0f20ee1562b98a Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 16 Apr 2014 17:15:55 +0200
Subject: [PATCH] ipa_range_check: Use special attributes to determine presence
of RID bases
The slapi_entry_attr_get_ulong which is used to get value of the RID base
attributes returns 0 in case the attribute is not set at all. We need
to distinguish this situation from the situation where RID base attributes
are present, but deliberately set to 0.
Otherwise this can cause false negative results of checks in the range_check
plugin.
Part of: https://fedorahosted.org/freeipa/ticket/4137
---
.../ipa-range-check/ipa_range_check.c | 40 +-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
index da5169e6e9bf74d5fbbf3aea40ee3e1a2c8f6016..68948f599aa4e6d21b071424ab27e3c62c0afefe 100644
--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
@@ -88,6 +88,8 @@ struct range_info {
uint32_t id_range_size;
uint32_t base_rid;
uint32_t secondary_base_rid;
+bool base_rid_set;
+bool secondary_base_rid_set;
};
static void free_range_info(struct range_info *range) {
@@ -281,6 +283,7 @@ static int slapi_entry_to_range_info(struct domain_info *domain_info_head,
int ret;
unsigned long ul_val;
struct range_info *range = NULL;
+Slapi_Attr *attr;
range = calloc(1, sizeof(struct range_info));
if (range == NULL) {
@@ -326,6 +329,20 @@ static int slapi_entry_to_range_info(struct domain_info *domain_info_head,
}
range-secondary_base_rid = ul_val;
+if (slapi_entry_attr_find(entry, IPA_BASE_RID, attr) == -1) {
+range-base_rid_set = false;
+}
+else {
+range-base_rid_set = true;
+}
+
+if (slapi_entry_attr_find(entry, IPA_SECONDARY_BASE_RID, attr) == -1) {
+range-secondary_base_rid_set = false;
+}
+else {
+range-secondary_base_rid_set = true;
+}
+
*_range = range;
ret = 0;
@@ -398,12 +415,14 @@ static int check_ranges(struct range_info *r1, struct range_info *r2)
/* For ipa-local or ipa-ad-trust range types primary RID ranges should
* not overlap */
+
if (strcasecmp(r1-id_range_type, AD_TRUST_RANGE_TYPE) == 0 ||
strcasecmp(r1-id_range_type, LOCAL_RANGE_TYPE) == 0) {
-/* Check if rid range overlaps with existing rid range */
-if (intervals_overlap(r1-base_rid, r2-base_rid,
-r1-id_range_size, r2-id_range_size))
+/* Check if primary rid range overlaps with existing primary rid range */
+if ((r1-base_rid_set r2-base_rid_set)
+intervals_overlap(r1-base_rid, r2-base_rid,
+ r1-id_range_size, r2-id_range_size))
return 2;
}
@@ -412,18 +431,21 @@ static int check_ranges(struct range_info *r1, struct range_info *r2)
/* Check if secondary RID range overlaps with existing secondary or
* primary RID range. */
-if (intervals_overlap(r1-secondary_base_rid,
-r2-secondary_base_rid, r1-id_range_size, r2-id_range_size))
+if ((r1-secondary_base_rid_set r2-secondary_base_rid_set)
+intervals_overlap(r1-secondary_base_rid, r2-secondary_base_rid,
+ r1-id_range_size, r2-id_range_size))
return 3;
/* Check if RID range overlaps with existing secondary RID range */
-if (intervals_overlap(r1-base_rid, r2-secondary_base_rid,
-r1-id_range_size, r2-id_range_size))
+if ((r1-base_rid_set r2-secondary_base_rid_set)
+intervals_overlap(r1-base_rid, r2-secondary_base_rid,
+ r1-id_range_size, r2-id_range_size))
return 4;
/* Check if secondary RID range overlaps with existing RID range */
-if (intervals_overlap(r1-secondary_base_rid, r2-base_rid,
-r1-id_range_size, r2-id_range_size))
+if ((r1-secondary_base_rid_set r2-base_rid_set)
+intervals_overlap(r1-secondary_base_rid, r2-base_rid,
+ r1-id_range_size, r2-id_range_size))
return 5;
}
}
--
1.8.5.3
From d714f77f1f162d1c7daeecf7a340f95ed3368f2d Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 16 Apr 2014
Re: [Freeipa-devel] [PATCHES] 255-259 Framework tweaks
ACK for 256 - 259. On 04/01/2014 10:45 AM, Jan Cholasta wrote: Hi, while working with Martin Bašti on issues in his dns plugin patches we ran into several limitations in the framework. The attached patches remove these limitations. Also, Tomáš Babej pointed out that when using --raw, all the attribute names should use letter casing as returned by python-ldap. Patch 259 implements that. See commit messages for details. Honza -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements
On Thu, 17 Apr 2014, Tomas Babej wrote:
From 43cd26a0a42c3b18e4dbb5c6ed0f20ee1562b98a Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 16 Apr 2014 17:15:55 +0200
Subject: [PATCH] ipa_range_check: Use special attributes to determine presence
of RID bases
The slapi_entry_attr_get_ulong which is used to get value of the RID base
attributes returns 0 in case the attribute is not set at all. We need
to distinguish this situation from the situation where RID base attributes
are present, but deliberately set to 0.
Otherwise this can cause false negative results of checks in the range_check
plugin.
Part of: https://fedorahosted.org/freeipa/ticket/4137
---
.../ipa-range-check/ipa_range_check.c | 40 +-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
index
da5169e6e9bf74d5fbbf3aea40ee3e1a2c8f6016..68948f599aa4e6d21b071424ab27e3c62c0afefe
100644
--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
@@ -88,6 +88,8 @@ struct range_info {
uint32_t id_range_size;
uint32_t base_rid;
uint32_t secondary_base_rid;
+bool base_rid_set;
+bool secondary_base_rid_set;
};
static void free_range_info(struct range_info *range) {
@@ -281,6 +283,7 @@ static int slapi_entry_to_range_info(struct domain_info
*domain_info_head,
int ret;
unsigned long ul_val;
struct range_info *range = NULL;
+Slapi_Attr *attr;
range = calloc(1, sizeof(struct range_info));
if (range == NULL) {
@@ -326,6 +329,20 @@ static int slapi_entry_to_range_info(struct domain_info
*domain_info_head,
}
range-secondary_base_rid = ul_val;
+if (slapi_entry_attr_find(entry, IPA_BASE_RID, attr) == -1) {
+range-base_rid_set = false;
+}
+else {
+range-base_rid_set = true;
+}
You replace this by
range-base_rid_set = (slapi_entry_attr_find(entry, IPA_BASE_RID, attr)
== -1);
+
+if (slapi_entry_attr_find(entry, IPA_SECONDARY_BASE_RID, attr) == -1) {
+range-secondary_base_rid_set = false;
+}
+else {
+range-secondary_base_rid_set = true;
+}
+
Same here.
*_range = range;
ret = 0;
@@ -398,12 +415,14 @@ static int check_ranges(struct range_info *r1, struct
range_info *r2)
/* For ipa-local or ipa-ad-trust range types primary RID ranges should
* not overlap */
+
if (strcasecmp(r1-id_range_type, AD_TRUST_RANGE_TYPE) == 0 ||
strcasecmp(r1-id_range_type, LOCAL_RANGE_TYPE) == 0) {
-/* Check if rid range overlaps with existing rid range */
-if (intervals_overlap(r1-base_rid, r2-base_rid,
-r1-id_range_size, r2-id_range_size))
+/* Check if primary rid range overlaps with existing primary rid
range */
+if ((r1-base_rid_set r2-base_rid_set)
+intervals_overlap(r1-base_rid, r2-base_rid,
+ r1-id_range_size, r2-id_range_size))
return 2;
}
@@ -412,18 +431,21 @@ static int check_ranges(struct range_info *r1, struct
range_info *r2)
/* Check if secondary RID range overlaps with existing secondary or
* primary RID range. */
-if (intervals_overlap(r1-secondary_base_rid,
-r2-secondary_base_rid, r1-id_range_size, r2-id_range_size))
+if ((r1-secondary_base_rid_set r2-secondary_base_rid_set)
+intervals_overlap(r1-secondary_base_rid,
r2-secondary_base_rid,
+ r1-id_range_size, r2-id_range_size))
return 3;
/* Check if RID range overlaps with existing secondary RID range */
-if (intervals_overlap(r1-base_rid, r2-secondary_base_rid,
-r1-id_range_size, r2-id_range_size))
+if ((r1-base_rid_set r2-secondary_base_rid_set)
+intervals_overlap(r1-base_rid, r2-secondary_base_rid,
+ r1-id_range_size, r2-id_range_size))
return 4;
/* Check if secondary RID range overlaps with existing RID range */
-if (intervals_overlap(r1-secondary_base_rid, r2-base_rid,
-r1-id_range_size, r2-id_range_size))
+if ((r1-secondary_base_rid_set r2-base_rid_set)
+intervals_overlap(r1-secondary_base_rid, r2-base_rid,
+ r1-id_range_size, r2-id_range_size))
return 5;
}
}
I know that is was in your original code, but can we get numbers
replaced by an enum? I'd prefer to see symbolic names used instead of
numbers.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
Re: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements
On Thu, 17 Apr 2014, Tomas Babej wrote: From d714f77f1f162d1c7daeecf7a340f95ed3368f2d Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Wed, 16 Apr 2014 17:20:55 +0200 Subject: [PATCH] ipa_range_check: Connect the new node of the linked list Part of: https://fedorahosted.org/freeipa/ticket/4137 --- daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c | 1 + 1 file changed, 1 insertion(+) diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c index 68948f599aa4e6d21b071424ab27e3c62c0afefe..20961d8810448a46514ab82c8cdc318e014db4fc 100644 --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c @@ -131,6 +131,7 @@ static int map_domain_to_root(struct domain_info **head, new_head-forest_root_id = slapi_entry_attr_get_charptr(root_domain, IPA_DOMAIN_ID); new_head-next = *head; +*head = new_head; return 0; } ACK -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements
On Thu, 17 Apr 2014, Tomas Babej wrote:
From 632c0ed1fca2cb48b981f6daac55badd59c9c263 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 16 Apr 2014 17:22:46 +0200
Subject: [PATCH] ipa_range_check: Make a new copy of forest_root_id attribute
for range_info struct
Not making a new copy of this attribute creates multiple frees caused by
multiple
pointers to the same forest_root_id from all the range_info structs for all the
domains belonging to given forest.
Part of: https://fedorahosted.org/freeipa/ticket/4137
---
daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
index
20961d8810448a46514ab82c8cdc318e014db4fc..e2affbd47dc54fb6180cffe842dc2395cf482f52
100644
--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
@@ -147,7 +147,7 @@ static char* get_forest_root_id(struct domain_info *head,
char* domain_id) {
if (domain_id != NULL) {
while(head) {
if (strcasecmp(head-domain_id, domain_id) == 0) {
-return head-forest_root_id;
+return slapi_ch_strdup(head-forest_root_id);
}
head = head-next;
}
ACK
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements
On Thu, 17 Apr 2014, Tomas Babej wrote:
From ed60bd0e865aad85eb1ffa02d8aea7f76220c65c Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 16 Apr 2014 17:26:07 +0200
Subject: [PATCH] ipa_range_check: Do not fail when no trusted domain is
available
When building the domain to forest root map, we need to take the case
of IPA server having no trusted domains configured at all. Do not abort
the checks, but return an empty map instead.
Part of: https://fedorahosted.org/freeipa/ticket/4137
---
daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
index
e2affbd47dc54fb6180cffe842dc2395cf482f52..b05b121f0e9cbc6fb6422b4d50f96cb7e86cda07
100644
--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
@@ -173,6 +173,8 @@ static int build_domain_to_forest_root_map(struct
domain_info **head,
int search_result;
int ret = 0;
+LOG(Building forest root map \n);
+
/* Set the base DN for the search to cn=ad, cn=trusts, $SUFFIX */
ret = asprintf(base, cn=ad,cn=trusts,%s, ctx-base_dn);
if (ret == -1) {
@@ -211,8 +213,14 @@ static int build_domain_to_forest_root_map(struct
domain_info **head,
ret = slapi_pblock_get(trusted_domain_search_pb, SLAPI_PLUGIN_INTOP_RESULT,
search_result);
if (ret != 0 || search_result != LDAP_SUCCESS) {
-LOG_FATAL(Internal search failed.\n);
-ret = LDAP_OPERATIONS_ERROR;
+
+/* If the search for the trusted domains fails,
+ * AD Trust support on IPA server is not available */
+
+LOG(No trusts support on IPA server.\n);
Please expand the message here, may be something like
LOG(Empty forest root map as trusts are not enabled on this IPA server\n);
+ret = 0;
+*head = NULL;
+
goto done;
}
Otherwise ACK.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 12 Call generate-rndc-key.sh during ipa-server-install
Hi,
this patch modifies ipa-server-install to warn the user, if there is
a lack of entropy, also runs generate-rndc-key.sh before named restart,
to ensure, that it can start before systemd timeouts.
Thanks
Adam
From d405cea8dae5a03ab0f9d429d3251e8be9ae9fe2 Mon Sep 17 00:00:00 2001
From: Adam Misnyovszki amisn...@redhat.com
Date: Wed, 16 Apr 2014 16:11:33 +0200
Subject: [PATCH] Call generate-rndc-key.sh during ipa-server-install
Since systemd has by default a 2 minute timeout to start
a service, the end of ipa-server-install might fail
because starting named times out. This patch ensures that
generate-rndc-key.sh runs before named service restart.
Also, warning message is displayed before KDC install and
generate-rndc-key.sh, if there is a lack of entropy, to
notify the user that the process could take more time
than expected.
https://fedorahosted.org/freeipa/ticket/4210
---
install/tools/ipa-server-install | 16
1 file changed, 16 insertions(+)
diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
index 34393b7df0a95a76b0c2660dcaafca13b21d2dfb..0e8a21cecc50578bc8bea84df3b7dc7afca1624e 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -38,6 +38,7 @@ import nss.error
import base64
import pwd
import textwrap
+import string
from optparse import OptionGroup, OptionValueError
try:
@@ -568,6 +569,14 @@ def set_subject_in_config(realm_name, dm_password, suffix, subject_base):
conn.update_entry(entry_attrs)
conn.disconnect()
+def check_entropy():
+try:
+with open('/proc/sys/kernel/random/entropy_avail', 'r') as efname:
+if string.atoi(efname.read()) 200:
+service.print_msg(WARNING: Your system is running out of entropy, expect long delays!)
+except:
+service.print_msg(Could not determine entropy, possible long delays)
+
def main():
global ds
@@ -1119,6 +1128,7 @@ def main():
# This is done within stopped_service context, which restarts CA
ca.enable_client_auth_to_db()
+check_entropy()
krb = krbinstance.KrbInstance(fstore)
if options.pkinit_pkcs12:
krb.create_instance(realm_name, host_name, domain_name,
@@ -1175,6 +1185,12 @@ def main():
service.print_msg(Restarting the certificate server)
ca.restart(dogtag.configured_constants().PKI_INSTANCE_NAME)
+# Make sure generate-rndc-key.sh runs before named restart
+if options.setup_dns:
+check_entropy()
+service.print_msg(Generate rndc key file)
+run(['/usr/libexec/generate-rndc-key.sh'])
+
# Create a BIND instance
bind = bindinstance.BindInstance(fstore, dm_password)
bind.setup(host_name, ip_address, realm_name, domain_name, dns_forwarders,
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Forward zone V4/Design draft
Hello,
I created draft to split forward and master zone.
http://www.freeipa.org/page/V4/Forward_zones#Questions
There is question: should it be implemented as new command set, or as
--type={master|forward} parameter only. For details see link above in
section Questions.
Martin^2 Basti
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements
On Thu, 17 Apr 2014, Tomas Babej wrote:
From 96f27c06f062dcfaa40405c50ad087d6013dc62c Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 16 Apr 2014 17:28:34 +0200
Subject: [PATCH] ipa_range_check: Fix typo when comparing strings using
strcasecmp
Part of: https://fedorahosted.org/freeipa/ticket/4137
---
daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
index
b05b121f0e9cbc6fb6422b4d50f96cb7e86cda07..794e7f3c81c283897059da28b52d7be93e8eb15b
100644
--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
@@ -397,10 +397,10 @@ static int check_ranges(struct range_info *r1, struct
range_info *r2)
/* Check if base range overlaps with existing base range.
* Exception: ipa-ad-trust-posix ranges from the same forest */
-if (!(strcasecmp(r1-id_range_type, AD_TRUST_POSIX_RANGE_TYPE)
- strcasecmp(r2-id_range_type, AD_TRUST_POSIX_RANGE_TYPE)
- r1-forest_root_id != NULL r2-forest_root_id !=NULL
- strcasecmp(r1-forest_root_id, r2-forest_root_id) == 0)) {
+if (!((strcasecmp(r1-id_range_type, AD_TRUST_POSIX_RANGE_TYPE) == 0)
+ (strcasecmp(r2-id_range_type, AD_TRUST_POSIX_RANGE_TYPE) == 0)
+ (r1-forest_root_id != NULL r2-forest_root_id != NULL)
+ (strcasecmp(r1-forest_root_id, r2-forest_root_id) == 0))) {
if (intervals_overlap(r1-base_id, r2-base_id,
r1-id_range_size, r2-id_range_size)){
ACK.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Forward zone V4/Design draft
On 04/17/2014 02:51 PM, Martin Basti wrote:
Hello,
I created draft to split forward and master zone.
http://www.freeipa.org/page/V4/Forward_zones#Questions
There is question: should it be implemented as new command set, or as
--type={master|forward} parameter only. For details see link above in
section Questions.
Martin^2 Basti
When I was discussing this with Martin, using a separate command seemed like
the best idea to me. Trying to cram both zones to one command would just
introduce all sort of hacks and workarounds in the framework.
Both DNS zones have different main objectclass, different set of required and
optional attributes and IMO cramming them all to one command would just make it
confusing (and the API as well). If you look for example at how AD organizes
DNS zones, it also does not cram all the zones to one view, but have 2
folders for Forward Lookup zones and for Conditional Forwarded zones.
Feedback welcome.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Managed permission versioning
I would like to discuss more on the managed read permissions upgrades [1].
Right now, we simply merge an old permission with the new one, making sure that
we only add new attributes instead of just replacing them, to prevent a managed
permission to be spoiled by a lower FreeIPA server version which runs an
updates.
I was thinking about it some more and seems to me we could run in problems when
we for example find out that some permission is too relaxed and we want to
remove some default attribute. Or when we want to update the permission filter.
Or when object has anonymous and authenticated permission and we want to move
attribute from anonymous to authenticated permission.
Changes like this can happen, especially in the first release and we do not
have means to address them. What about simply versioning the permissions as we
do with our configs? I.e.
1) Introduce new MUST numeric attribute ipaPermVersion
2) Add 'version' field to managed permissions:
managed_permissions = {
'System: Read Roles': {
'version': 1,
'replaces_global_anonymous_aci': True,
'ipapermbindruletype': 'permission',
'ipapermright': {'read', 'search', 'compare'},
'ipapermdefaultattr': {
'businesscategory', 'cn', 'description', 'member', 'memberof',
'o', 'objectclass', 'ou', 'owner', 'seealso',
},
'default_privileges': {'RBAC Readers'},
},
}
3) Modify updater to only update the permission if it's version is higher than
the one in LDAP. In that case, it should simply replace the managed permission
attributes with the new one, no merging (except the attributes that we allow
users to change).
When we want to change the permission, we simply do the changes, bump the
version and we are done and we do not need to fear some older FreeIPA will
overwrite it. That of course assumes that the versioning would be available
from FreeIPA 4.0.
Makes sense?
[1] http://www.freeipa.org/page/V3/Managed_Read_permissions
--
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] [PATCH] 12 Call generate-rndc-key.sh during ipa-server-install
Misnyovszki Adam wrote: Hi, this patch modifies ipa-server-install to warn the user, if there is a lack of entropy, also runs generate-rndc-key.sh before named restart, to ensure, that it can start before systemd timeouts. I think the exception should be logged in check_entropy() in case this every does fail (the file name changes, the format changes, etc). There should be a try/except around the run() call. I noticed that /etc/rndc.key isn't removed on uninstall, which I guess means the same key will be re-used. Should we be removing that? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 12 Call generate-rndc-key.sh during ipa-server-install
On 04/17/2014 04:10 PM, Rob Crittenden wrote: Misnyovszki Adam wrote: Hi, this patch modifies ipa-server-install to warn the user, if there is a lack of entropy, also runs generate-rndc-key.sh before named restart, to ensure, that it can start before systemd timeouts. I think the exception should be logged in check_entropy() in case this every does fail (the file name changes, the format changes, etc). There should be a try/except around the run() call. I noticed that /etc/rndc.key isn't removed on uninstall, which I guess means the same key will be re-used. Should we be removing that? rob Also, bare exceptions are bad! +except: +service.print_msg(Could not determine entropy, possible long delays) Next, you do all the checks in ipa-server-install, while they should be in service files, like krbinstance.py so that it is also checked in other installers, like ipa-replica-install. Same for DNS, it should be a separate step in bindinstance.py so that when the installation is hanging, you can see [X/Y] Generating rndc key file and know that it is hanging on that part. I would not misuse service.print_msg for regular messages, I would only do the service.print_msg(WARNING: Your system is running out of entropy, expect long delays!) others can be either turn into separate installation step or debug log message. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 11 - CI - test_forced_client_reenrollment stability fix
On 04/16/2014 04:21 PM, Misnyovszki Adam wrote: 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 Adam ACK, pushed to: master: f85fe1e8513327396ef2f9732810abdffc88abba ipa-3-3: 1d16370dc536434e63097115150afab26febd5b4 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 585 webui: fix OTP Token add regression
On 04/15/2014 03:21 PM, Misnyovszki Adam wrote: On Tue, 15 Apr 2014 09:54:22 +0200 Petr Vobornik pvobo...@redhat.com wrote: OTP Token add failed because of invalid function call. qr_widget doesn't contain `on_value_changed` method since it inherits from `IPA.widget` and not from `IPA.input_widget`. Emitting the event was preserved for future possible usage. https://fedorahosted.org/freeipa/ticket/4306 ACK Greets Adam Pushed to master: c644b47492e22370bc71f57e5ac46b50f9b4e247 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 255-259 Framework tweaks
On 04/17/2014 02:33 PM, Tomas Babej wrote: ACK for 256 - 259. On 04/01/2014 10:45 AM, Jan Cholasta wrote: Hi, while working with Martin Bašti on issues in his dns plugin patches we ran into several limitations in the framework. The attached patches remove these limitations. Also, Tomáš Babej pointed out that when using --raw, all the attribute names should use letter casing as returned by python-ldap. Patch 259 implements that. See commit messages for details. Sorry for the delay. There are some conflicts with master, could you please rebase? -- Petr³ ___ 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 Thu, Apr 17, 2014 at 01:25:08PM +0300, Alexander Bokovoy wrote: On Thu, 17 Apr 2014, Sumit Bose wrote: On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: On 04/15/2014 05:13 AM, Sumit Bose wrote: Hi, #* Shall we allow different UIDs/GIDs in different views? Yes. I hope the admin knows what he does in this case. I think it's similar like with the user name, is there really a user-case for this with cannot be solved better by creating a new user with the given UID? Think about what happens if a host is moved to a new host group e.g. to change the HBAC rules but by chance has now a different view with different UIDs? Again, question is what purpose would such view serve? Given that only new SSSD version can resolve these views properly and a likely reason for deviating would be to present such a user somewhere on a legacy system, I see certain conflict of use case wishes. It just came to my mind that it is even more complicated. Although the use case is to provide UIDs and GIDs if they are not set in AD we have to handle the case where they are set in AD. What if there are now two different override views for this AD user one with one without a override UID . In the case where a override UID is given imo the override UID should be used. But I wonder what would be the right way if e.g. there is only a shell attribute in the override view for the user? Shall we assume that the user will have the UID set in AD and have different UIDs in different views again or none at all, because there is none given in the view? I think the best way to solve this is to say that in all views the UID will be the same. If the override UID is set the AD user will get this UID. If the override UID is not set then it depends on the AD settings. If a UID is set in AD the user will get this one from AD if not he will have none at all, which is fine for the web apps use-case. If we can agree on this we should consider to modify the suggested LDAP schema so that it is possible to e.g. have different shells and home directories in different views but always the same UID/GID settings. bye, Sumit ___ 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 Thu, 17 Apr 2014, Sumit Bose wrote: On Thu, Apr 17, 2014 at 01:25:08PM +0300, Alexander Bokovoy wrote: On Thu, 17 Apr 2014, Sumit Bose wrote: On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: On 04/15/2014 05:13 AM, Sumit Bose wrote: Hi, #* Shall we allow different UIDs/GIDs in different views? Yes. I hope the admin knows what he does in this case. I think it's similar like with the user name, is there really a user-case for this with cannot be solved better by creating a new user with the given UID? Think about what happens if a host is moved to a new host group e.g. to change the HBAC rules but by chance has now a different view with different UIDs? Again, question is what purpose would such view serve? Given that only new SSSD version can resolve these views properly and a likely reason for deviating would be to present such a user somewhere on a legacy system, I see certain conflict of use case wishes. It just came to my mind that it is even more complicated. Although the use case is to provide UIDs and GIDs if they are not set in AD we have to handle the case where they are set in AD. What if there are now two different override views for this AD user one with one without a override UID . In the case where a override UID is given imo the override UID should be used. But I wonder what would be the right way if e.g. there is only a shell attribute in the override view for the user? Shall we assume that the user will have the UID set in AD and have different UIDs in different views again or none at all, because there is none given in the view? I think the best way to solve this is to say that in all views the UID will be the same. If the override UID is set the AD user will get this UID. If the override UID is not set then it depends on the AD settings. If a UID is set in AD the user will get this one from AD if not he will have none at all, which is fine for the web apps use-case. Exactly. If we can agree on this we should consider to modify the suggested LDAP schema so that it is possible to e.g. have different shells and home directories in different views but always the same UID/GID settings. +1 -- / Alexander Bokovoy ___ 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 Thu, 2014-04-17 at 17:20 +0200, Sumit Bose wrote: On Thu, Apr 17, 2014 at 01:25:08PM +0300, Alexander Bokovoy wrote: On Thu, 17 Apr 2014, Sumit Bose wrote: On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: On 04/15/2014 05:13 AM, Sumit Bose wrote: Hi, #* Shall we allow different UIDs/GIDs in different views? Yes. I hope the admin knows what he does in this case. I think it's similar like with the user name, is there really a user-case for this with cannot be solved better by creating a new user with the given UID? Think about what happens if a host is moved to a new host group e.g. to change the HBAC rules but by chance has now a different view with different UIDs? Clearly this and administration mistake, and not something we should try to address. Use different groups for HBAC and UID views, period. Again, question is what purpose would such view serve? Given that only new SSSD version can resolve these views properly and a likely reason for deviating would be to present such a user somewhere on a legacy system, I see certain conflict of use case wishes. We cannot do anything for legacy clients, short of presenting multiple views in LDAP, but *how* do you know which view to show a client ? It just came to my mind that it is even more complicated. Although the use case is to provide UIDs and GIDs if they are not set in AD we have to handle the case where they are set in AD. What if there are now two different override views for this AD user one with one without a override UID . If you centralize them, each view needs its own cache, that is quite non-negotiable. In the case where a override UID is given imo the override UID should be used. clearly But I wonder what would be the right way if e.g. there is only a shell attribute in the override view for the user? The process is simple. for any one client only one view exist. A view is taking the original user, and then overlaying on top only the attributes explicitly set for that user on the specific view. So any attribute that is not overridden is maintained. Shall we assume that the user will have the UID set in AD and have different UIDs in different views again or none at all, because there is none given in the view? Yes, you shall assume that. I think the best way to solve this is to say that in all views the UID will be the same. Absolutely not, it would completely defeat the point of having views. If the override UID is set the AD user will get this UID. If the override UID is not set then it depends on the AD settings. This is correct. If a UID is set in AD the user will get this one from AD if not he will have none at all, which is fine for the web apps use-case. If there is none and SSSD does automatic mapping, then that's what SSSD will set. If we can agree on this we should consider to modify the suggested LDAP schema so that it is possible to e.g. have different shells and home directories in different views but always the same UID/GID settings. No, I do not agree at all, the most important feature of views is not changing home directories, but being able to maintain a different uid because all the local files (which spread on some shared storage) for a group of servers have historically a different uid for the user than the rest of the infrastructure (NIS domains consolidation case). Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name
Hello, While working on the trust permissions I found a typo in the 'ipanttrustauthoutgoing' attribute in default_attributes. Here is a fix. -- Petr³ From ef98055a524dffbe98098def896f40592a3fdac4 Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Thu, 17 Apr 2014 19:06:52 +0200 Subject: [PATCH] trust plugin: Fix typo in attribute name --- ipalib/plugins/trust.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index f57cf7d891928903fdbee67697b96db4ad2679b7..428d6463de092f378458f837fe7ea9ad002a4480 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -307,7 +307,7 @@ class trust(LDAPObject): object_class = ['ipaNTTrustedDomain'] default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', 'ipanttrusttype', 'ipanttrustattributes', 'ipanttrustdirection', 'ipanttrustpartner', -'ipantauthtrustoutgoing', 'ipanttrustauthincoming', 'ipanttrustforesttrustinfo', +'ipanttrustauthoutgoing', 'ipanttrustauthincoming', 'ipanttrustforesttrustinfo', 'ipanttrustposixoffset', 'ipantsupportedencryptiontypes' ] search_display_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', 'ipanttrusttype', -- 1.9.0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0239-0243] Refactor ldap_parse_master_zoneentry()
Hello,
This patch set attempts to move ldap_parse_master_zoneentry() a little bit
closer to sane code.
It is preparation for
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
--
Petr^2 Spacek
From bfa03960c700bedda454bb7cef5c89bbfce1bbba Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Tue, 15 Apr 2014 18:57:40 +0200
Subject: [PATCH] Refactor empty zone handling.
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c | 79 +--
1 file changed, 47 insertions(+), 32 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 6c2ead85459eaf531311a15c5817acb4117e7618..790ac4a597dca8772ddb3eed8a6f91d43c7f6b1f 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -715,10 +715,12 @@ destroy_ldap_connection(ldap_connection_t **ldap_connp)
/* Test if the existing zone is 'empty zone' per RFC 6303. */
static isc_boolean_t ATTR_NONNULLS ATTR_CHECKRESULT
-zone_isempty(isc_mem_t *mctx, dns_zone_t *zone) {
+zone_isempty(dns_zone_t *zone) {
char **argv = NULL;
+ isc_mem_t *mctx = NULL;
isc_boolean_t result = ISC_FALSE;
+ mctx = dns_zone_getmctx(zone);
if (dns_zone_getdbtype(zone, argv, mctx) != ISC_R_SUCCESS)
CLEANUP_WITH(ISC_FALSE);
@@ -833,6 +835,42 @@ cleanup:
return result;
}
+/**
+ * Unload empty zone from given view.
+ *
+ * @retval ISC_R_EXISTS if a zone with given name is not an empty zone
+ * @retval ISC_R_SUCCESS if name was an empty zone
+ *and it was unloaded successfully
+ * @retval ISC_R_NOTFOUND if name does not match any zone in given view
+ * @retval other errors
+ */
+static isc_result_t ATTR_NONNULLS ATTR_CHECKRESULT
+zone_unload_ifempty(dns_view_t *view, dns_name_t *name) {
+ isc_result_t result;
+ dns_zone_t *zone = NULL;
+ char zone_name[DNS_NAME_FORMATSIZE];
+
+ CHECK(dns_view_findzone(view, name, zone));
+
+ if (zone_isempty(zone) == ISC_TRUE) {
+ dns_name_format(name, zone_name, DNS_NAME_FORMATSIZE);
+ result = delete_bind_zone(view-zonetable, zone);
+ if (result != ISC_R_SUCCESS)
+ log_error_r(unable to unload automatic empty zone
+%s, zone_name);
+ else
+ log_info(automatic empty zone %s unloaded,
+ zone_name);
+ } else {
+ result = ISC_R_EXISTS;
+ }
+
+cleanup:
+ if (zone != NULL)
+ dns_zone_detach(zone);
+ return result;
+}
+
/*
* Create a new zone with origin 'name'. The zone will be added to the
* ldap_inst-view.
@@ -845,44 +883,18 @@ create_zone(ldap_instance_t *ldap_inst, dns_name_t *name, dns_zone_t **zonep)
const char *argv[2];
sync_state_t sync_state;
isc_task_t *task = NULL;
+ char zone_name[DNS_NAME_FORMATSIZE];
REQUIRE(ldap_inst != NULL);
REQUIRE(name != NULL);
REQUIRE(zonep != NULL *zonep == NULL);
argv[0] = ldapdb_impname;
argv[1] = ldap_inst-db_name;
- result = dns_view_findzone(ldap_inst-view, name, zone);
- if (result != ISC_R_NOTFOUND) {
- char zone_name[DNS_NAME_FORMATSIZE];
- dns_name_format(name, zone_name, DNS_NAME_FORMATSIZE);
-
- if (result != ISC_R_SUCCESS) {
- log_error_r(dns_view_findzone() failed while
-searching for zone '%s', zone_name);
- } else { /* zone already exists */
- if (zone_isempty(ldap_inst-mctx, zone) == ISC_TRUE) {
-result = delete_bind_zone(ldap_inst-view-zonetable,
- zone);
-if (result != ISC_R_SUCCESS)
- log_error_r(failed to create new zone
- '%s': unable to unload
- automatic empty zone,
- zone_name);
-else
- log_info(automatic empty zone %s
- unloaded, zone_name);
-
- } else {
-result = ISC_R_EXISTS;
-log_error_r(failed to create new zone '%s',
- zone_name);
- }
- }
- if (result != ISC_R_SUCCESS)
- goto cleanup;
- }
+ result = zone_unload_ifempty(ldap_inst-view, name);
+ if (result != ISC_R_SUCCESS result != ISC_R_NOTFOUND)
+ goto cleanup;
CHECK(dns_zone_create(zone, ldap_inst-mctx));
CHECK(dns_zone_setorigin(zone, name));
@@ -901,6 +913,9 @@ create_zone(ldap_instance_t *ldap_inst, dns_name_t *name, dns_zone_t **zonep)
return ISC_R_SUCCESS;
cleanup:
+ dns_name_format(name, zone_name, DNS_NAME_FORMATSIZE);
+ log_error_r(failed to create new zone '%s', zone_name);
+
if (zone != NULL) {
if (dns_zone_getmgr(zone) != NULL)
dns_zonemgr_releasezone(ldap_inst-zmgr, zone);
@@ -1403,7 +1418,7 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst,
result = dns_zt_find(inst-view-zonetable, name, 0, NULL,
zone);
if (result == ISC_R_SUCCESS || result == DNS_R_PARTIALMATCH) {
- if (zone_isempty(inst-mctx, zone)) {
+ if (zone_isempty(zone)) {
dns_zone_log(zone, ISC_LOG_INFO, automatic
empty zone will be shut down
to enable forwarding);
--
1.9.0
From 4b7618495a05f80c0cd383be2e48cce6d36f4442 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Tue, 15 Apr 2014 19:21:56 +0200
Subject: [PATCH] Rename
Re: [Freeipa-devel] Managed permission versioning
On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote:
I would like to discuss more on the managed read permissions upgrades [1].
Right now, we simply merge an old permission with the new one, making sure
that
we only add new attributes instead of just replacing them, to prevent a
managed
permission to be spoiled by a lower FreeIPA server version which runs an
updates.
I was thinking about it some more and seems to me we could run in problems
when
we for example find out that some permission is too relaxed and we want to
remove some default attribute. Or when we want to update the permission
filter.
Or when object has anonymous and authenticated permission and we want to move
attribute from anonymous to authenticated permission.
Changes like this can happen, especially in the first release and we do not
have means to address them. What about simply versioning the permissions as we
do with our configs? I.e.
1) Introduce new MUST numeric attribute ipaPermVersion
2) Add 'version' field to managed permissions:
managed_permissions = {
'System: Read Roles': {
'version': 1,
'replaces_global_anonymous_aci': True,
'ipapermbindruletype': 'permission',
'ipapermright': {'read', 'search', 'compare'},
'ipapermdefaultattr': {
'businesscategory', 'cn', 'description', 'member', 'memberof',
'o', 'objectclass', 'ou', 'owner', 'seealso',
},
'default_privileges': {'RBAC Readers'},
},
}
3) Modify updater to only update the permission if it's version is higher than
the one in LDAP. In that case, it should simply replace the managed permission
attributes with the new one, no merging (except the attributes that we allow
users to change).
When we want to change the permission, we simply do the changes, bump the
version and we are done and we do not need to fear some older FreeIPA will
overwrite it. That of course assumes that the versioning would be available
from FreeIPA 4.0.
Makes sense?
[1] http://www.freeipa.org/page/V3/Managed_Read_permissions
Uhmm, yes, and no, let me explain.
What you say *does* make sense, but you are being too focused :-)
The upgrade issue is not limited to permissions, but affects everything.
I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
script. if this number is higher than what we know we immediately stop
and do not perform updates that affect anything but our own server data.
This will protect the whole tree from unintentional changes caused by an
older replica.
Makes sense ?
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] Managed permission versioning
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote:
I would like to discuss more on the managed read permissions upgrades [1].
Right now, we simply merge an old permission with the new one, making sure that
we only add new attributes instead of just replacing them, to prevent a managed
permission to be spoiled by a lower FreeIPA server version which runs an
updates.
I was thinking about it some more and seems to me we could run in problems when
we for example find out that some permission is too relaxed and we want to
remove some default attribute. Or when we want to update the permission filter.
Or when object has anonymous and authenticated permission and we want to move
attribute from anonymous to authenticated permission.
Changes like this can happen, especially in the first release and we do not
have means to address them. What about simply versioning the permissions as we
do with our configs? I.e.
1) Introduce new MUST numeric attribute ipaPermVersion
2) Add 'version' field to managed permissions:
managed_permissions = {
'System: Read Roles': {
'version': 1,
'replaces_global_anonymous_aci': True,
'ipapermbindruletype': 'permission',
'ipapermright': {'read', 'search', 'compare'},
'ipapermdefaultattr': {
'businesscategory', 'cn', 'description', 'member', 'memberof',
'o', 'objectclass', 'ou', 'owner', 'seealso',
},
'default_privileges': {'RBAC Readers'},
},
}
3) Modify updater to only update the permission if it's version is higher than
the one in LDAP. In that case, it should simply replace the managed permission
attributes with the new one, no merging (except the attributes that we allow
users to change).
When we want to change the permission, we simply do the changes, bump the
version and we are done and we do not need to fear some older FreeIPA will
overwrite it. That of course assumes that the versioning would be available
from FreeIPA 4.0.
Makes sense?
[1] http://www.freeipa.org/page/V3/Managed_Read_permissions
Uhmm, yes, and no, let me explain.
What you say *does* make sense, but you are being too focused :-)
The upgrade issue is not limited to permissions, but affects everything.
I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
script. if this number is higher than what we know we immediately stop
and do not perform updates that affect anything but our own server data.
This will protect the whole tree from unintentional changes caused by an
older replica.
Makes sense ?
This could lead to new features not working. Those features would rely
on containers, ACIs, etc to exist but they wouldn't if the updates
aren't run.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name
On 04/17/2014 07:11 PM, Petr Viktorin wrote:
Hello,
While working on the trust permissions I found a typo in the
'ipanttrustauthoutgoing' attribute in default_attributes. Here is a fix.
I think the right question to ask - do we want to have
ipanttrustauth{incoming,outgoing} in default attributes?
I do not think so. It is supposed to hold a secret for the trust, I do not
think you want it displayed on your terminal by default - even if you have a
right to display it.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Managed permission versioning
On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote:
I would like to discuss more on the managed read permissions upgrades [1].
Right now, we simply merge an old permission with the new one, making sure
that
we only add new attributes instead of just replacing them, to prevent a
managed
permission to be spoiled by a lower FreeIPA server version which runs an
updates.
I was thinking about it some more and seems to me we could run in problems
when
we for example find out that some permission is too relaxed and we want to
remove some default attribute. Or when we want to update the permission
filter.
Or when object has anonymous and authenticated permission and we want to
move
attribute from anonymous to authenticated permission.
Changes like this can happen, especially in the first release and we do not
have means to address them. What about simply versioning the permissions
as we
do with our configs? I.e.
1) Introduce new MUST numeric attribute ipaPermVersion
2) Add 'version' field to managed permissions:
managed_permissions = {
'System: Read Roles': {
'version': 1,
'replaces_global_anonymous_aci': True,
'ipapermbindruletype': 'permission',
'ipapermright': {'read', 'search', 'compare'},
'ipapermdefaultattr': {
'businesscategory', 'cn', 'description', 'member',
'memberof',
'o', 'objectclass', 'ou', 'owner', 'seealso',
},
'default_privileges': {'RBAC Readers'},
},
}
3) Modify updater to only update the permission if it's version is higher
than
the one in LDAP. In that case, it should simply replace the managed
permission
attributes with the new one, no merging (except the attributes that we
allow
users to change).
When we want to change the permission, we simply do the changes, bump the
version and we are done and we do not need to fear some older FreeIPA will
overwrite it. That of course assumes that the versioning would be available
from FreeIPA 4.0.
Makes sense?
[1] http://www.freeipa.org/page/V3/Managed_Read_permissions
Uhmm, yes, and no, let me explain.
What you say *does* make sense, but you are being too focused :-)
The upgrade issue is not limited to permissions, but affects everything.
I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
script. if this number is higher than what we know we immediately stop
and do not perform updates that affect anything but our own server data.
This will protect the whole tree from unintentional changes caused by an
older replica.
Makes sense ?
This could lead to new features not working. Those features would rely
on containers, ACIs, etc to exist but they wouldn't if the updates
aren't run.
Sorry I don't get this, if they are new features, then the version will
be older and the update *will* run and at the end raise the version.
We just prevent old updates from running and current updates from
running multiple times, for the shared tree.
Do we depend on having updates run multiple times for the data in the
shared tree ?
Note that I am not saying that all updates should stop, any update for
cn=config would still need to be run on each server (although setting a
version there too would probably be beneficial).
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] 530 trust plugin: Fix typo in attribute name
On Thu, 2014-04-17 at 20:30 +0200, Martin Kosek wrote:
On 04/17/2014 07:11 PM, Petr Viktorin wrote:
Hello,
While working on the trust permissions I found a typo in the
'ipanttrustauthoutgoing' attribute in default_attributes. Here is a fix.
I think the right question to ask - do we want to have
ipanttrustauth{incoming,outgoing} in default attributes?
I do not think so. It is supposed to hold a secret for the trust, I do not
think you want it displayed on your terminal by default - even if you have a
right to display it.
Yep, should not be returned by default to any command line utility.
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] 530 trust plugin: Fix typo in attribute name
On Thu, 17 Apr 2014, Simo Sorce wrote:
On Thu, 2014-04-17 at 20:30 +0200, Martin Kosek wrote:
On 04/17/2014 07:11 PM, Petr Viktorin wrote:
Hello,
While working on the trust permissions I found a typo in the
'ipanttrustauthoutgoing' attribute in default_attributes. Here is a fix.
I think the right question to ask - do we want to have
ipanttrustauth{incoming,outgoing} in default attributes?
I do not think so. It is supposed to hold a secret for the trust, I do not
think you want it displayed on your terminal by default - even if you have a
right to display it.
Yep, should not be returned by default to any command line utility.
Agreed. I wanted to remove it too the other day but forgot to file a
ticket.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Managed permission versioning
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote:
I would like to discuss more on the managed read permissions upgrades [1].
Right now, we simply merge an old permission with the new one, making sure that
we only add new attributes instead of just replacing them, to prevent a managed
permission to be spoiled by a lower FreeIPA server version which runs an
updates.
I was thinking about it some more and seems to me we could run in problems when
we for example find out that some permission is too relaxed and we want to
remove some default attribute. Or when we want to update the permission filter.
Or when object has anonymous and authenticated permission and we want to move
attribute from anonymous to authenticated permission.
Changes like this can happen, especially in the first release and we do not
have means to address them. What about simply versioning the permissions as we
do with our configs? I.e.
1) Introduce new MUST numeric attribute ipaPermVersion
2) Add 'version' field to managed permissions:
managed_permissions = {
'System: Read Roles': {
'version': 1,
'replaces_global_anonymous_aci': True,
'ipapermbindruletype': 'permission',
'ipapermright': {'read', 'search', 'compare'},
'ipapermdefaultattr': {
'businesscategory', 'cn', 'description', 'member', 'memberof',
'o', 'objectclass', 'ou', 'owner', 'seealso',
},
'default_privileges': {'RBAC Readers'},
},
}
3) Modify updater to only update the permission if it's version is higher than
the one in LDAP. In that case, it should simply replace the managed permission
attributes with the new one, no merging (except the attributes that we allow
users to change).
When we want to change the permission, we simply do the changes, bump the
version and we are done and we do not need to fear some older FreeIPA will
overwrite it. That of course assumes that the versioning would be available
from FreeIPA 4.0.
Makes sense?
[1] http://www.freeipa.org/page/V3/Managed_Read_permissions
Uhmm, yes, and no, let me explain.
What you say *does* make sense, but you are being too focused :-)
The upgrade issue is not limited to permissions, but affects everything.
I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
script. if this number is higher than what we know we immediately stop
and do not perform updates that affect anything but our own server data.
This will protect the whole tree from unintentional changes caused by an
older replica.
Makes sense ?
This could lead to new features not working. Those features would rely
on containers, ACIs, etc to exist but they wouldn't if the updates
aren't run.
Sorry I don't get this, if they are new features, then the version will
be older and the update *will* run and at the end raise the version.
We just prevent old updates from running and current updates from
running multiple times, for the shared tree.
Do we depend on having updates run multiple times for the data in the
shared tree ?
Note that I am not saying that all updates should stop, any update for
cn=config would still need to be run on each server (although setting a
version there too would probably be beneficial).
Ok, so the update runs, adds data, which gets replicated out to
potentially old servers, and we're at the place you said we wouldn't be.
Updates are all loaded and sorted so that all changes to a given DN
should be applied at once, so it isn't like applying a old update and a
new update are two separate operations. In fact, it would likely be a
no-op in the case that they have already been applied.
Do you have any examples to clarify your concerns? I'm not following you.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Managed permission versioning
On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote:
I would like to discuss more on the managed read permissions upgrades
[1].
Right now, we simply merge an old permission with the new one, making
sure that
we only add new attributes instead of just replacing them, to prevent a
managed
permission to be spoiled by a lower FreeIPA server version which runs an
updates.
I was thinking about it some more and seems to me we could run in
problems when
we for example find out that some permission is too relaxed and we want
to
remove some default attribute. Or when we want to update the permission
filter.
Or when object has anonymous and authenticated permission and we want to
move
attribute from anonymous to authenticated permission.
Changes like this can happen, especially in the first release and we do
not
have means to address them. What about simply versioning the permissions
as we
do with our configs? I.e.
1) Introduce new MUST numeric attribute ipaPermVersion
2) Add 'version' field to managed permissions:
managed_permissions = {
'System: Read Roles': {
'version': 1,
'replaces_global_anonymous_aci': True,
'ipapermbindruletype': 'permission',
'ipapermright': {'read', 'search', 'compare'},
'ipapermdefaultattr': {
'businesscategory', 'cn', 'description', 'member',
'memberof',
'o', 'objectclass', 'ou', 'owner', 'seealso',
},
'default_privileges': {'RBAC Readers'},
},
}
3) Modify updater to only update the permission if it's version is
higher than
the one in LDAP. In that case, it should simply replace the managed
permission
attributes with the new one, no merging (except the attributes that we
allow
users to change).
When we want to change the permission, we simply do the changes, bump the
version and we are done and we do not need to fear some older FreeIPA
will
overwrite it. That of course assumes that the versioning would be
available
from FreeIPA 4.0.
Makes sense?
[1] http://www.freeipa.org/page/V3/Managed_Read_permissions
Uhmm, yes, and no, let me explain.
What you say *does* make sense, but you are being too focused :-)
The upgrade issue is not limited to permissions, but affects everything.
I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
script. if this number is higher than what we know we immediately stop
and do not perform updates that affect anything but our own server data.
This will protect the whole tree from unintentional changes caused by an
older replica.
Makes sense ?
This could lead to new features not working. Those features would rely
on containers, ACIs, etc to exist but they wouldn't if the updates
aren't run.
Sorry I don't get this, if they are new features, then the version will
be older and the update *will* run and at the end raise the version.
We just prevent old updates from running and current updates from
running multiple times, for the shared tree.
Do we depend on having updates run multiple times for the data in the
shared tree ?
Note that I am not saying that all updates should stop, any update for
cn=config would still need to be run on each server (although setting a
version there too would probably be beneficial).
Ok, so the update runs, adds data, which gets replicated out to
potentially old servers, and we're at the place you said we wouldn't be.
I am not following you, the aim here is not to avoid replicating new
data to old server, the aim is that if you update the rpm of an older
replica and the rpm runs the ldap updater with the *old* code, we do not
end up with that updater *undoing* what a more recent update did.
Updates are all loaded and sorted so that all changes to a given DN
should be applied at once, so it isn't like applying a old update and a
new update are two separate operations. In fact, it would likely be a
no-op in the case that they have already been applied.
Do you have any examples to clarify your concerns? I'm not following you.
Sure at some point version freeipa version 4.2 is released and it has an
update that changes a default object so that now attribute 'foo' is
added, this is done through the updater.
Later on we release freeipa version 5.0 and we realize we will have
again to remove attribute 'foo' because we never really needed it, plus
if it is still there it causes issues to new feature XYZ.
The admin installs 5.0 and all are happy, then a week later he runs a
simply yum update on th eolder replicas still running 4.2
Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust
On 04/17/2014 05:15 AM, Sumit Bose wrote: On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: 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. Thank you for your feedback, it was very helpful but I'm afraid it might also caused some new questions. = 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. Quite some time ago we have decided to not mix algorithmic mapping and manually managed POSIX IDs. E.g. think about the case where a view with POSIX ID was added for an existing user which already has an algorithmic ID assigned on some clients. I think this is unfortunate but I can live with this though it is not best. If there is a workaround to have two trusts or two ranges associated with the forest with different mapping properties I am fine but we need to have that be clearly explain on a page because people were asking about this and I unfortunately gave them the wrong answer becuase I was not aware of the decision. IMO the decision seems contour intuitive to me. Here is the use cases that people explained to me: I had to put and manage my posix attributes in AD using third party solution. But as soon as I migrate to IPA I want the AD side of the company to stop managing posix attributes. I was under wrong assumption that though we do not have views now they can do what we ask by allowing the algorithmic mapping to kick in for new users. Frankly I do not see a reason why we can't assign posix attributes using algorithmic method if the posix attributes are not explicitly set. I can argue that this can be an optional fall back but it should be possible. I expect that there will be bugs filed about it as people try. We will see. I think the admin has to decide what he wants. He wants to use what he already has from AD but then use other mappings on top. Since we do not provide views yet the only expected option is to fall back to algorithmic mapping. Below you mentioned a migration use case where old users should keep their IDs but new users will get algorithmically generated ones. I think this is bad practice and technically is it next to impossible without additional admin effort to decide if a given AD user is an old or a new user. May be
Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust
On Thu, 2014-04-17 at 23:58 -0400, Dmitri Pal wrote: yes, this can already be controlled by the idrange type. But you have to choose either algorithmic or manual mapping you cannot have both in a given domain. What you can do is to create a domain in the AD forest for the old users and one for the new users. Now you can use manual mapping for the old-users-domain and algorithmic mapping for the new-users-domain. If this requires moving users between domains on AD side then this is a non starter. The more I read it the more I think that decision is wrong and it is bug. What we can do is halfway, if an overlay view is activate for an AD domain then in IPA we have options to automatically generate IDs for any AD user (if the admin wants), these IDs get stored in the Ad overlaying view. From the SSSD pov no algoritmic mapping is occurring as SSSD always looks for the IDs in IPA. Note that we have to do this anyway if you want to allow also legacy clients to see the same ids, so it seem to me the best/only possible way. The only caveat is that it requires some development on the IPA side to do this object creation, but it is not a lot of code as we can reuse DNA for the actual ID allocation, we just need to create the entry in the view. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
