Re: [Freeipa-devel] Reorganization of Web UI navigation items
On 06/04/2014 08:34 AM, Martin Kosek wrote: ... Users - Users - Groups - SUDO Hosts - Hosts - Host groups - Services - Netgroups - Automount Authentication - OTP Tokens - Password Policy - Kerberos Ticket Policy Policy - HBAC - SELinux User Maps - Automember Alternatively, we could rename Policy to Authorization as both HBAC and SELinux is about authorizing what an authenticated user can do. We would just need to move Automember to different place, though this one is difficult - it relates both to Users and Hosts, just like Netgroup. Trusts - Trust configuration - Trusts - (future) Views Infrastructure - Certificates - DNS - (future) Replication topology - (future) Vault Configuration - Global - Access Control (RBAC) - Realm Domains - ID Ranges Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Reorganization of Web UI navigation items
On 4.6.2014 08:44, Martin Kosek wrote: On 06/04/2014 08:34 AM, Martin Kosek wrote: ... This is really good proposal! Scroll down to see three nit picks: Users - Users - Groups - SUDO Hosts - Hosts - Host groups - Services - Netgroups - Automount Authentication - OTP Tokens - Password Policy - Kerberos Ticket Policy Policy - HBAC - SELinux User Maps - Automember Alternatively, we could rename Policy to Authorization as both HBAC and SELinux is about authorizing what an authenticated user can do. We would just need to move Automember to different place, though this one is difficult - it relates both to Users and Hosts, just like Netgroup. Trusts - Trust configuration - Trusts - (future) Views Infrastructure - Certificates ^^^ I would like to see this under Authentication. Nowaways it is used to authenticate machines and it will be extended to user authentication as soon as Smart Card support is added. - DNS - (future) Replication topology ^^^ Personally, I would place it under IPA Configuration. - (future) Vault ^^^ Why is Vault under Infrastructure? It sounds like Authentication to me. It is meant to store plain-text passwords etc., no? It seems that I'm proposing to reduce Infrastructure to DNS. We can move DNS somewhere or make DNS top-level item until we get DHCP or something similar. This also opens the question if DNS management is really the right business for us :-) I'm personally not sure :-) Configuration ^^^ Can it be IPA configuration or something like that? Just Configuration seems too vague to me. After all, everything in the UI is some kind of configuration :-) - Global - Access Control (RBAC) - Realm Domains - ID Ranges -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Reorganization of Web UI navigation items
On 4.6.2014 09:37, Petr Spacek wrote: On 4.6.2014 08:44, Martin Kosek wrote: On 06/04/2014 08:34 AM, Martin Kosek wrote: ... This is really good proposal! Scroll down to see three nit picks: Users - Users - Groups - SUDO Hosts - Hosts - Host groups - Services - Netgroups - Automount Authentication - OTP Tokens - Password Policy - Kerberos Ticket Policy Policy - HBAC - SELinux User Maps - Automember Alternatively, we could rename Policy to Authorization as both HBAC and SELinux is about authorizing what an authenticated user can do. We would just need to move Automember to different place, though this one is difficult - it relates both to Users and Hosts, just like Netgroup. Trusts - Trust configuration - Trusts - (future) Views Infrastructure - Certificates ^^^ I would like to see this under Authentication. Nowaways it is used to authenticate machines and it will be extended to user authentication as soon as Smart Card support is added. - DNS - (future) Replication topology ^^^ Personally, I would place it under IPA Configuration. - (future) Vault ^^^ Why is Vault under Infrastructure? It sounds like Authentication to me. It is meant to store plain-text passwords etc., no? It seems that I'm proposing to reduce Infrastructure to DNS. We can move DNS somewhere or make DNS top-level item until we get DHCP or something similar. I would rather avoid having a temporary top-level item. This also opens the question if DNS management is really the right business for us :-) I'm personally not sure :-) Configuration ^^^ Can it be IPA configuration or something like that? Just Configuration seems too vague to me. After all, everything in the UI is some kind of configuration :-) We can leave the old IPA Server name. I agree that Replication topology could be here because it configures the tool and not the data, similar to other items under this category. But I think that many users would try to find it in infrastructure. - Global - Access Control (RBAC) - Realm Domains - ID Ranges -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0565 ipalib.aci: Fix bugs in comparison
On 06/03/2014 01:44 PM, Petr Viktorin wrote: I found two bugs in the ACI comparison code, one new and one old. This fixes them and adds some more tests. ACK. Pushed to master: a2aca68f63c2e442dc9e103ae31ba0c67d606186 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions
On 06/03/2014 02:41 PM, Petr Viktorin wrote: On 05/28/2014 04:36 PM, Petr Viktorin wrote: On 05/28/2014 04:27 PM, Petr Viktorin wrote: On 05/27/2014 04:20 PM, Martin Kosek wrote: On 05/26/2014 04:44 PM, Petr Viktorin wrote: On 05/22/2014 03:07 PM, Petr Viktorin wrote: Hello, Here I start upgrading the existing default permissions to the new Managed style. https://fedorahosted.org/freeipa/ticket/4346 The patches rely on my patch 0551 (https://fedorahosted.org/freeipa/ticket/4349) You may run into what seems to be a 389 bug. If you get a Midair Collision (NO_SUCH_ATTRIBUTE) error, restart the DS and try running ipa-ldap-updater again. I'm working with Ludwig on this one. The operation is now described at http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions If there user has modified an old default permission, a warning is logged the replacement permission is not added/updated. The user needs to evaluate the situation: either update the old permission to match the original default, or remove the old permission, and then run ipa-ldap-updater will create the new one. Is bailing out the right thing to do if the old entry was modified? Forcing user to remove old permission and create new one seems as a too much work to me. After the upgrade, we need to be sure that the managed permissions is there. Note that this only happens if the user changed the permissions, so we need to be extra careful to respect their wishes. What is the problem of having both 2 permissions in the DS? The old modified permission and the new system managed one? As we are dealing with allow permissions, having 2 of them should be harmless. The new one could be granting too much access, the admin might have wanted to restrict the defaults. It could be possible to parse the permission, figure out the changes the user made, and apply them to the new one, but that seems like too much guesswork to me. Maybe we could do the same we do with managed permissions upgrades? Only allow differences in the list of attributes? I am thinking that people could hotfix missing attributes at permissions themselves (like adding description to sudorule permission), this would lead to duplicate permissions later. What we could do when old ACI differs only in allowed attributes is to compare it to defaults and set whitelist and blacklist attributes of the new managed permission. Then we can safely delete the old ACI (with warning). If you think this is too much work, we can keep the old behavior and just add duplicate ACI. Having duplicate permissions would be possible, after all they have a different name. However I'd expect that most people would still want to delete the old ones, rather than letting them hide among user-defined permissions. On the other hand, my approach has a downside as well: if the 'memberallowcmd' attribute was removed from 'Modify Sudo rule', there's now no way to upgrade while allowing access but keeping that attribute off-limits, short of writing deny a ACI by hand. How big a problem is this? It might be worth it to create a special tool that upgrades a single permission and allows setting the excluded/included attributes explicitly. This problem would be removed with my approach proposed above. There are some interesting scenarios to think about with respect to upgrades and user changes: * Upgrade to old version, e.g. - have IPA 3.2 master, IPA 3.2 replica - upgrade master to 4.0 (old permissions are updated) - then upgrade replica to 3.3 (old permissions are added again!) This is AFAIK not supported but it does happen. We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will always add the old permissions, but with this patch, a subsequent upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the old permissions again. Hm, I think this is the best option we have. We should warn about this behavior in our release notes though. Tied to that is another scenario: * Re-create permissions with old names - have IPA 4.0 master - Create a permission named 'Modify Sudo rule' - Upgrade to IPA 4.1 Here we need to make sure the new permission is *not* removed, because a new 'Modify Sudo rule' permission is no longer special in any way. To ensure this the updater only removes old-style permissions. Right, we can decide based on objectclasses - whether permissionsv2 OC is there or not. One thing that can happen when 4.0 masters are still mixed with 3.x is that an old permission named 'Modify Sudo rule' is added on the old server. Any update to 4.0+ will remove that. Old-style default permissions were sorta-kinda managed by IPA itself anyway, so users should expect this. We should still point it out in the docs though, since I expect some users to start messing with the permissions before upgrading all of the infrastructure to
Re: [Freeipa-devel] Move replication topology to the shared tree
On 06/02/2014 10:46 AM, Ludwig Krispenz wrote: Ticket 4302 is a request for an enhancement: Move replication topology to the shared tree There has been some discussion in comments in the ticket, but I'd like to open the discussion to a wider audience to get an agreement on what should be implemented, before writing a design spec. The implementation requires a new IPA plugin for 389 DS and eventually an enhancement of the 389 replication plugin (which depends on some decisions below). In the following I will use the terms “topology plugin” for the new plugin and “replication plugin” for the existing 389 multimaster replication plugin. Lets start with the requirements: What should be achieved by this RFE ? In my opinion there are three different levels of features to implement with this request - providing all replication configuration information consistent across all deployed servers on all servers, eg to easily visualize the replication topology. - Allowing to do sanity checks on replication configuration, denying modifications which would break replication topology or issue warnings. - Use the information in the shared tree to trigger changes to the replication configuration in the corresponding servers, this means to allow to completely control replication configuration with modifications of entries in the shared tree The main questions are 1] which information is needed in the shared tree (eg what params in the repl config should be modifiable) 2] how is the information organized and stored (layout of the repl config information shared tree) 3] how is the interaction of the info in the shared tree and configuration in cn=config and the interaction between the topology plugin and the replication plugin ad 1] to verify the topology, eg connectivity info about all existing replication agreements is needed, the replication agreements only contain info about the target, and the parameters for connection to the target, but not about the origin. If the data have to evaluated on any server, information about the origin has to be added, eg replicaID, serverID,... In addition, if agreement config has to be changed based on the shared tree all required parameters need to be present, eg replicatedAttributeList, strippedAttrs, replicationEnabled, . Replication agreements only provide information on connections where replication is configured, if connectivity is to be checked independent info about all deployed serevers/replicas is needed. If topology should be validated, do we need params definig requirements, eg each replica to be connected to 1,2,3,... others, type of topology (ring, mesh, star,.) ? ad 2] the data required are available in the replicationAgreement (and eventually replica) entries, but the question is if there should be a 1:1 relationship to entries in the shared tree or a condensed representation, if there should be a server or connection oriented view. In my opinion a 1:1 relation is straight forward, easy to handle and easy to extend (not the full data of a repl agreement need to be present, other attributes are possible). The downside may be a larger number of entries, but this is no problem for the directory server and replication and the utilities eg to visualize a topology will handle this. If the number of entries should be reduced information on multiple replication agreements would have to be stored in one entry, and the problem arises ho to group data belonging to one agreement. LDAP does not provide a simple way to group attribute values in one entry, so all the info related to one agreement (origin, target, replicated attrs and other repl configuration info) could be stored in a single attribute, which will make the attribute as nicely readable and managable as acis. If topology verification and connectivity check is an integral part of the feature, I think a connection oriented view is not sufficient, it might be incomplete, so a server view is required, the server entry would then have the connection information as subentries or as attributes. Ad 3] The replication configuration is stored under cn=config and can be modified either by ldap operations or by editing the dse.ldif. With the topology plugin another source of configuration changes comes into play. The first question is: which information has precendence ? I think if there is info in the shared tree it should be used, and the information in cn=config should be updated. This also means that the topology plugin needs to intercept all mods to the entries in cn=config and have them ignored and handle all updates to the shared tree and trigger changes to the cn=config entries, which then would trigger rebuilds of the in memory replication objects. Next question: How to handle changes directly done in the dse.ldif, if everything should be done by the topology plugin it would have to verify and compare the info in
Re: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions
On 06/04/2014 10:15 AM, Martin Kosek wrote: On 06/03/2014 02:41 PM, Petr Viktorin wrote: On 05/28/2014 04:36 PM, Petr Viktorin wrote: On 05/28/2014 04:27 PM, Petr Viktorin wrote: On 05/27/2014 04:20 PM, Martin Kosek wrote: On 05/26/2014 04:44 PM, Petr Viktorin wrote: On 05/22/2014 03:07 PM, Petr Viktorin wrote: Hello, Here I start upgrading the existing default permissions to the new Managed style. https://fedorahosted.org/freeipa/ticket/4346 The patches rely on my patch 0551 (https://fedorahosted.org/freeipa/ticket/4349) You may run into what seems to be a 389 bug. If you get a Midair Collision (NO_SUCH_ATTRIBUTE) error, restart the DS and try running ipa-ldap-updater again. I'm working with Ludwig on this one. The operation is now described at http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions If there user has modified an old default permission, a warning is logged the replacement permission is not added/updated. The user needs to evaluate the situation: either update the old permission to match the original default, or remove the old permission, and then run ipa-ldap-updater will create the new one. Is bailing out the right thing to do if the old entry was modified? Forcing user to remove old permission and create new one seems as a too much work to me. After the upgrade, we need to be sure that the managed permissions is there. Note that this only happens if the user changed the permissions, so we need to be extra careful to respect their wishes. What is the problem of having both 2 permissions in the DS? The old modified permission and the new system managed one? As we are dealing with allow permissions, having 2 of them should be harmless. The new one could be granting too much access, the admin might have wanted to restrict the defaults. It could be possible to parse the permission, figure out the changes the user made, and apply them to the new one, but that seems like too much guesswork to me. Maybe we could do the same we do with managed permissions upgrades? Only allow differences in the list of attributes? I am thinking that people could hotfix missing attributes at permissions themselves (like adding description to sudorule permission), this would lead to duplicate permissions later. What we could do when old ACI differs only in allowed attributes is to compare it to defaults and set whitelist and blacklist attributes of the new managed permission. Then we can safely delete the old ACI (with warning). If you think this is too much work, we can keep the old behavior and just add duplicate ACI. Having duplicate permissions would be possible, after all they have a different name. However I'd expect that most people would still want to delete the old ones, rather than letting them hide among user-defined permissions. On the other hand, my approach has a downside as well: if the 'memberallowcmd' attribute was removed from 'Modify Sudo rule', there's now no way to upgrade while allowing access but keeping that attribute off-limits, short of writing deny a ACI by hand. How big a problem is this? It might be worth it to create a special tool that upgrades a single permission and allows setting the excluded/included attributes explicitly. This problem would be removed with my approach proposed above. There are some interesting scenarios to think about with respect to upgrades and user changes: * Upgrade to old version, e.g. - have IPA 3.2 master, IPA 3.2 replica - upgrade master to 4.0 (old permissions are updated) - then upgrade replica to 3.3 (old permissions are added again!) This is AFAIK not supported but it does happen. We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will always add the old permissions, but with this patch, a subsequent upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the old permissions again. Hm, I think this is the best option we have. We should warn about this behavior in our release notes though. Tied to that is another scenario: * Re-create permissions with old names - have IPA 4.0 master - Create a permission named 'Modify Sudo rule' - Upgrade to IPA 4.1 Here we need to make sure the new permission is *not* removed, because a new 'Modify Sudo rule' permission is no longer special in any way. To ensure this the updater only removes old-style permissions. Right, we can decide based on objectclasses - whether permissionsv2 OC is there or not. One thing that can happen when 4.0 masters are still mixed with 3.x is that an old permission named 'Modify Sudo rule' is added on the old server. Any update to 4.0+ will remove that. Old-style default permissions were sorta-kinda managed by IPA itself anyway, so users should expect this. We should still point it out in the docs though, since I expect some users to start messing with the permissions before upgrading all of the infrastructure to 4.0. +1, I would just point out
Re: [Freeipa-devel] Reorganization of Web UI navigation items
On 4.6.2014 09:55, Petr Vobornik wrote: On 4.6.2014 09:37, Petr Spacek wrote: On 4.6.2014 08:44, Martin Kosek wrote: On 06/04/2014 08:34 AM, Martin Kosek wrote: ... This is really good proposal! Scroll down to see three nit picks: Users - Users - Groups - SUDO Hosts - Hosts - Host groups - Services - Netgroups - Automount Authentication - OTP Tokens - Password Policy - Kerberos Ticket Policy Policy - HBAC - SELinux User Maps - Automember Alternatively, we could rename Policy to Authorization as both HBAC and SELinux is about authorizing what an authenticated user can do. We would just need to move Automember to different place, though this one is difficult - it relates both to Users and Hosts, just like Netgroup. Trusts - Trust configuration - Trusts - (future) Views Infrastructure - Certificates ^^^ I would like to see this under Authentication. Nowaways it is used to authenticate machines and it will be extended to user authentication as soon as Smart Card support is added. - DNS - (future) Replication topology ^^^ Personally, I would place it under IPA Configuration. - (future) Vault ^^^ Why is Vault under Infrastructure? It sounds like Authentication to me. It is meant to store plain-text passwords etc., no? It seems that I'm proposing to reduce Infrastructure to DNS. We can move DNS somewhere or make DNS top-level item until we get DHCP or something similar. I would rather avoid having a temporary top-level item. Temporary ~ years in this case. Is it good enough? :-) I personally don't like categories with one item in them, it seems ridiculous. Look at Time menu in OrangeHRM :-) You have to go through it just to click to the only option inside. Ridiculous. This also opens the question if DNS management is really the right business for us :-) I'm personally not sure :-) Configuration ^^^ Can it be IPA configuration or something like that? Just Configuration seems too vague to me. After all, everything in the UI is some kind of configuration :-) We can leave the old IPA Server name. I agree that Replication topology could be here because it configures the tool and not the data, similar to other items under this category. But I think that many users would try to find it in infrastructure. My point is that distinction between Infrastructure and IPA server or it's configuration is really vague. I'm worried that people (or at least I) will always look in the wrong category first which makes me unhappy. - Global - Access Control (RBAC) BTW can we clarify somehow that this applies purely to IPA? Maybe IPA Server category will make it clear enough... - Realm Domains - ID Ranges -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0567 test_permission_plugin: limit results in targetfilter find test
A test fix.
Pushed as one-liner to master: 3974c75053c165f7f9bc931fbd9925f16d1a07bb
--
Petr³
The IPA test suite goes green!
From fecd012c5dc27929b800fcd9e85c91e9fe80124c Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 4 Jun 2014 11:39:16 +0200
Subject: [PATCH] test_permission_plugin: limit results in targetfilter find
test
The test was finding recently added default permissions. Limit it to
the test permission only.
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
ipatests/test_xmlrpc/test_permission_plugin.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipatests/test_xmlrpc/test_permission_plugin.py b/ipatests/test_xmlrpc/test_permission_plugin.py
index 24585beaeecff19e685a785be96ed503e2f065a2..a37876bea5c2d666548f7efa94f32ddbf044c0b4 100644
--- a/ipatests/test_xmlrpc/test_permission_plugin.py
+++ b/ipatests/test_xmlrpc/test_permission_plugin.py
@@ -2432,7 +2432,7 @@ class test_permission_targetfilter(Declarative):
dict(
desc='Search for %r using %s %s' % (permission1, value_name, option_name),
command=(
-'permission_find', [],
+'permission_find', [permission1],
{option_name: value, 'all': True}
),
expected=dict(
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Move replication topology to the shared tree
On 06/04/2014 10:43 AM, thierry bordaz wrote: So my proposal would contain the following components 1] Store replication configuration in the shared tree in a combination of server and connection view (think we need both) and map replication configuration to these entries. I would prefer a direct mapping (with a subset of the cn=config attributes and required additions) About adding a new server in the replication topology. If it was initialized, it may register itself into the shared tree and then join the topology. If it was not initialized, it can be initialized online by one of the master. Will it be triggered with an update to the shared tree ? I think this has to be decided, I proposed some kind of bootstrapping: If the topology plugin is enabled and started it would check if there is already info on the connections for this server and if not create/update the entry in the shared tree, this could also happen if a new server is added. But Simo wanted to have the info in the shared tree indepndent of what was already configured. One problem with the automatic approach is what should be done if the config differs on the already deployed servers ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions
On 06/04/2014 10:43 AM, Petr Viktorin wrote: On 06/04/2014 10:15 AM, Martin Kosek wrote: On 06/03/2014 02:41 PM, Petr Viktorin wrote: On 05/28/2014 04:36 PM, Petr Viktorin wrote: On 05/28/2014 04:27 PM, Petr Viktorin wrote: On 05/27/2014 04:20 PM, Martin Kosek wrote: On 05/26/2014 04:44 PM, Petr Viktorin wrote: On 05/22/2014 03:07 PM, Petr Viktorin wrote: Hello, Here I start upgrading the existing default permissions to the new Managed style. https://fedorahosted.org/freeipa/ticket/4346 The patches rely on my patch 0551 (https://fedorahosted.org/freeipa/ticket/4349) You may run into what seems to be a 389 bug. If you get a Midair Collision (NO_SUCH_ATTRIBUTE) error, restart the DS and try running ipa-ldap-updater again. I'm working with Ludwig on this one. The operation is now described at http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions If there user has modified an old default permission, a warning is logged the replacement permission is not added/updated. The user needs to evaluate the situation: either update the old permission to match the original default, or remove the old permission, and then run ipa-ldap-updater will create the new one. Is bailing out the right thing to do if the old entry was modified? Forcing user to remove old permission and create new one seems as a too much work to me. After the upgrade, we need to be sure that the managed permissions is there. Note that this only happens if the user changed the permissions, so we need to be extra careful to respect their wishes. What is the problem of having both 2 permissions in the DS? The old modified permission and the new system managed one? As we are dealing with allow permissions, having 2 of them should be harmless. The new one could be granting too much access, the admin might have wanted to restrict the defaults. It could be possible to parse the permission, figure out the changes the user made, and apply them to the new one, but that seems like too much guesswork to me. Maybe we could do the same we do with managed permissions upgrades? Only allow differences in the list of attributes? I am thinking that people could hotfix missing attributes at permissions themselves (like adding description to sudorule permission), this would lead to duplicate permissions later. What we could do when old ACI differs only in allowed attributes is to compare it to defaults and set whitelist and blacklist attributes of the new managed permission. Then we can safely delete the old ACI (with warning). If you think this is too much work, we can keep the old behavior and just add duplicate ACI. Having duplicate permissions would be possible, after all they have a different name. However I'd expect that most people would still want to delete the old ones, rather than letting them hide among user-defined permissions. On the other hand, my approach has a downside as well: if the 'memberallowcmd' attribute was removed from 'Modify Sudo rule', there's now no way to upgrade while allowing access but keeping that attribute off-limits, short of writing deny a ACI by hand. How big a problem is this? It might be worth it to create a special tool that upgrades a single permission and allows setting the excluded/included attributes explicitly. This problem would be removed with my approach proposed above. There are some interesting scenarios to think about with respect to upgrades and user changes: * Upgrade to old version, e.g. - have IPA 3.2 master, IPA 3.2 replica - upgrade master to 4.0 (old permissions are updated) - then upgrade replica to 3.3 (old permissions are added again!) This is AFAIK not supported but it does happen. We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will always add the old permissions, but with this patch, a subsequent upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the old permissions again. Hm, I think this is the best option we have. We should warn about this behavior in our release notes though. Tied to that is another scenario: * Re-create permissions with old names - have IPA 4.0 master - Create a permission named 'Modify Sudo rule' - Upgrade to IPA 4.1 Here we need to make sure the new permission is *not* removed, because a new 'Modify Sudo rule' permission is no longer special in any way. To ensure this the updater only removes old-style permissions. Right, we can decide based on objectclasses - whether permissionsv2 OC is there or not. One thing that can happen when 4.0 masters are still mixed with 3.x is that an old permission named 'Modify Sudo rule' is added on the old server. Any update to 4.0+ will remove that. Old-style default permissions were sorta-kinda managed by IPA itself anyway, so users should expect this. We should still point it out in the docs though, since I expect
Re: [Freeipa-devel] [PATCH 0258] Fix run-time zone addition for secure zones
On 3.6.2014 10:53, Petr Spacek wrote:
Hello,
Fix run-time zone addition for secure zones.
Here comes fix for the fix ...
We really need a test-suite for bind-dyndb-ldap.
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
--
Petr^2 Spacek
From d2b59b0e0a6d175602d36b8c01b1f54d3b64e11a Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Mon, 2 Jun 2014 18:07:26 +0200
Subject: [PATCH] Fix run-time zone addition for secure zones.
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
---
src/ldap_helper.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 1e2d9a983504d5bc29f577c5bfbdbde407ebc380..cdf62588b1058a09885883bdaa4b67edde1b2792 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -2213,6 +2213,7 @@ ldap_parse_master_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst,
dns_name_t name;
dns_zone_t *raw = NULL;
dns_zone_t *secure = NULL;
+ dns_zone_t *toview = NULL;
isc_result_t result;
isc_boolean_t unlock = ISC_FALSE;
isc_boolean_t new_zone = ISC_FALSE;
@@ -2292,13 +2293,10 @@ ldap_parse_master_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst,
CHECK(zr_get_zone_settings(inst-zone_register, name, zone_settings));
CHECK(zone_master_reconfigure(entry, zone_settings, raw, secure, task));
- sync_state_get(inst-sctx, sync_state);
- if (new_zone == ISC_TRUE sync_state == sync_finished)
- CHECK(publish_zone(task, inst, raw));
-
/* synchronize zone origin with LDAP */
CHECK(zr_get_zone_dbs(inst-zone_register, name, ldapdb, rbtdb));
CHECK(dns_db_newversion(ldapdb, version));
+ sync_state_get(inst-sctx, sync_state);
CHECK(zone_sync_apex(inst, entry, name, sync_state, new_zone,
ldapdb, rbtdb, version,
diff, new_serial, ldap_writeback,
@@ -2335,8 +2333,14 @@ ldap_parse_master_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst,
}
/* Do zone load only if the initial LDAP synchronization is done. */
- if (sync_state == sync_finished data_changed == ISC_TRUE)
- CHECK(load_zone(secure));
+ if (sync_state == sync_finished) {
+ toview = (want_secure == ISC_TRUE) ? secure : raw;
+ if (new_zone == ISC_TRUE) {
+ CHECK(publish_zone(task, inst, toview));
+ }
+ if (data_changed == ISC_TRUE)
+ CHECK(load_zone(toview));
+ }
cleanup:
dns_diff_clear(diff);
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Reorganization of Web UI navigation items
On Wed, 2014-06-04 at 08:44 +0200, Martin Kosek wrote: On 06/04/2014 08:34 AM, Martin Kosek wrote: ... Users - Users - Groups - SUDO Hosts - Hosts - Host groups - Services - Netgroups - Automount Authentication - OTP Tokens - Password Policy - Kerberos Ticket Policy Policy - HBAC - SELinux User Maps - Automember Alternatively, we could rename Policy to Authorization as both HBAC and SELinux is about authorizing what an authenticated user can do. We would just need to move Automember to different place, though this one is difficult - it relates both to Users and Hosts, just like Netgroup. I do not see the need to do Policy - Authorization but Automember is in the wrong place imo. The first tab should be Users - Accounts and include automember in it as automember is about groupings ? Actually I would merge the current Users and Hosts tabs into 'Accounts' (or maybe 'Identities' ?) and add Automember. 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] [PATCHES] 0552-0554 Upgrading write permissions
On 06/04/2014 05:23 PM, Martin Kosek wrote: On 06/04/2014 10:43 AM, Petr Viktorin wrote: On 06/04/2014 10:15 AM, Martin Kosek wrote: On 06/03/2014 02:41 PM, Petr Viktorin wrote: On 05/28/2014 04:36 PM, Petr Viktorin wrote: On 05/28/2014 04:27 PM, Petr Viktorin wrote: On 05/27/2014 04:20 PM, Martin Kosek wrote: On 05/26/2014 04:44 PM, Petr Viktorin wrote: On 05/22/2014 03:07 PM, Petr Viktorin wrote: Hello, Here I start upgrading the existing default permissions to the new Managed style. https://fedorahosted.org/freeipa/ticket/4346 The patches rely on my patch 0551 (https://fedorahosted.org/freeipa/ticket/4349) You may run into what seems to be a 389 bug. If you get a Midair Collision (NO_SUCH_ATTRIBUTE) error, restart the DS and try running ipa-ldap-updater again. I'm working with Ludwig on this one. The operation is now described at http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions If there user has modified an old default permission, a warning is logged the replacement permission is not added/updated. The user needs to evaluate the situation: either update the old permission to match the original default, or remove the old permission, and then run ipa-ldap-updater will create the new one. Is bailing out the right thing to do if the old entry was modified? Forcing user to remove old permission and create new one seems as a too much work to me. After the upgrade, we need to be sure that the managed permissions is there. Note that this only happens if the user changed the permissions, so we need to be extra careful to respect their wishes. What is the problem of having both 2 permissions in the DS? The old modified permission and the new system managed one? As we are dealing with allow permissions, having 2 of them should be harmless. The new one could be granting too much access, the admin might have wanted to restrict the defaults. It could be possible to parse the permission, figure out the changes the user made, and apply them to the new one, but that seems like too much guesswork to me. Maybe we could do the same we do with managed permissions upgrades? Only allow differences in the list of attributes? I am thinking that people could hotfix missing attributes at permissions themselves (like adding description to sudorule permission), this would lead to duplicate permissions later. What we could do when old ACI differs only in allowed attributes is to compare it to defaults and set whitelist and blacklist attributes of the new managed permission. Then we can safely delete the old ACI (with warning). If you think this is too much work, we can keep the old behavior and just add duplicate ACI. Having duplicate permissions would be possible, after all they have a different name. However I'd expect that most people would still want to delete the old ones, rather than letting them hide among user-defined permissions. On the other hand, my approach has a downside as well: if the 'memberallowcmd' attribute was removed from 'Modify Sudo rule', there's now no way to upgrade while allowing access but keeping that attribute off-limits, short of writing deny a ACI by hand. How big a problem is this? It might be worth it to create a special tool that upgrades a single permission and allows setting the excluded/included attributes explicitly. This problem would be removed with my approach proposed above. There are some interesting scenarios to think about with respect to upgrades and user changes: * Upgrade to old version, e.g. - have IPA 3.2 master, IPA 3.2 replica - upgrade master to 4.0 (old permissions are updated) - then upgrade replica to 3.3 (old permissions are added again!) This is AFAIK not supported but it does happen. We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will always add the old permissions, but with this patch, a subsequent upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the old permissions again. Hm, I think this is the best option we have. We should warn about this behavior in our release notes though. Tied to that is another scenario: * Re-create permissions with old names - have IPA 4.0 master - Create a permission named 'Modify Sudo rule' - Upgrade to IPA 4.1 Here we need to make sure the new permission is *not* removed, because a new 'Modify Sudo rule' permission is no longer special in any way. To ensure this the updater only removes old-style permissions. Right, we can decide based on objectclasses - whether permissionsv2 OC is there or not. One thing that can happen when 4.0 masters are still mixed with 3.x is that an old permission named 'Modify Sudo rule' is added on the old server. Any update to 4.0+ will remove that. Old-style default permissions were sorta-kinda managed by IPA itself anyway, so users should expect this. We should still point it out in the docs though, since I expect some users to start messing
Re: [Freeipa-devel] Move replication topology to the shared tree
On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote: On 06/04/2014 10:43 AM, thierry bordaz wrote: So my proposal would contain the following components 1] Store replication configuration in the shared tree in a combination of server and connection view (think we need both) and map replication configuration to these entries. I would prefer a direct mapping (with a subset of the cn=config attributes and required additions) About adding a new server in the replication topology. If it was initialized, it may register itself into the shared tree and then join the topology. If it was not initialized, it can be initialized online by one of the master. Will it be triggered with an update to the shared tree ? I think this has to be decided, I proposed some kind of bootstrapping: If the topology plugin is enabled and started it would check if there is already info on the connections for this server and if not create/update the entry in the shared tree, this could also happen if a new server is added. You mean updating the shared tree from information about replication agreements found in cn=config ? I can see how this would be useful in migration from previous server versions, but I fear would cause issues if you remove a connection when one of the 2 servers is down. When you bring the server up it would try to re-create a connection that was deleted by the admin. It's a catch-22 which is why I want the shared tree to be authoritative but not the cn=config tree. But Simo wanted to have the info in the shared tree indepndent of what was already configured. It's not much about being independent, it's about what is authoritative and what is not. One problem with the automatic approach is what should be done if the config differs on the already deployed servers That's just one of many problems. I think cn=config entries should be read an injected in the shared topology only once at upgrade time, but not anymore after. Maybe this calls for adding nodes to the topology tree, if the topology plugin starts and the server is not in the topology tree, then it sources the local configuration, then adds itself and the connections to the topology tree. If the node is already in the topology tree this step is always skipped. Or something similar (could be just a flag in cn=masters objects). 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
[Freeipa-devel] User life Cycle: referential integrity
Hello, I am looking at the appropriate way to configure DS referential integrity and I am hitting some issues about its scoping and which attributes need to be preserved. User A and B are both Active. User A refers user B for example 'owner: DN user B in Active container'. If entry A is deleted (user-del), it keeps 'owner: DN user B in Active container'. Do we really want to preserve such attributes (owner, member, seeAlso...) in case the user is coming back (user-undel) ? If it makes sense we may achieve this if we extends RI to both 'Active' and 'Delete' container. If we prefer to remove such attributes, then 'user-del' is a MODRDN followed by some MODs or a ADD-DEL where the Delete entry is rebuilt from the 'Active' entry. This is a similar problem when using 'stageuser-add id --from-delete', the references may become invalid (unless RI also covers Staging). An option would be to accept to have invalid references in 'staging' and 'delete', but when the entry is stageuser-activate/user-undel the reference are checked and removed if invalid. Here invalid means, the referred entry does not exist or is not 'Active'. thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life Cycle: referential integrity
On Wed, 2014-06-04 at 17:46 +0200, thierry bordaz wrote: Hello, I am looking at the appropriate way to configure DS referential integrity and I am hitting some issues about its scoping and which attributes need to be preserved. User A and B are both Active. User A refers user B for example 'owner: DN user B in Active container'. If entry A is deleted (user-del), it keeps 'owner: DN user B in Active container'. Do we really want to preserve such attributes (owner, member, seeAlso...) in case the user is coming back (user-undel) ? No, when a user is deleted all references to it in the rest of the tree should be removed. the entries it references can stay I guess, the user is deleted so no harm should come from it having dangling DNs in its attributes. If it makes sense we may achieve this if we extends RI to both 'Active' and 'Delete' container. Nope, makes no sense. If we prefer to remove such attributes, then 'user-del' is a MODRDN followed by some MODs or a ADD-DEL where the Delete entry is rebuilt from the 'Active' entry. Delete must be a modrdn, we cannot delete the entry and re-add it. This is a similar problem when using 'stageuser-add id --from-delete', the references may become invalid (unless RI also covers Staging). There should be no references in either staged or delete users, or they should be adjusted when the user is unstaged/undeleted. An option would be to accept to have invalid references in 'staging' and 'delete', but when the entry is stageuser-activate/user-undel the reference are checked and removed if invalid. Here invalid means, the referred entry does not exist or is not 'Active'. Yup, this sounds right, when you activate the user references need to be checked and adjusted accordingly. 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] Move replication topology to the shared tree
On 06/04/2014 05:41 PM, Simo Sorce wrote: On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote: On 06/04/2014 10:43 AM, thierry bordaz wrote: So my proposal would contain the following components 1] Store replication configuration in the shared tree in a combination of server and connection view (think we need both) and map replication configuration to these entries. I would prefer a direct mapping (with a subset of the cn=config attributes and required additions) About adding a new server in the replication topology. If it was initialized, it may register itself into the shared tree and then join the topology. If it was not initialized, it can be initialized online by one of the master. Will it be triggered with an update to the shared tree ? I think this has to be decided, I proposed some kind of bootstrapping: If the topology plugin is enabled and started it would check if there is already info on the connections for this server and if not create/update the entry in the shared tree, this could also happen if a new server is added. You mean updating the shared tree from information about replication agreements found in cn=config ? I can see how this would be useful in migration from previous server versions, but I fear would cause issues if you remove a connection when one of the 2 servers is down. When you bring the server up it would try to re-create a connection that was deleted by the admin. It's a catch-22 which is why I want the shared tree to be authoritative but not the cn=config tree. But Simo wanted to have the info in the shared tree indepndent of what was already configured. It's not much about being independent, it's about what is authoritative and what is not. One problem with the automatic approach is what should be done if the config differs on the already deployed servers That's just one of many problems. I think cn=config entries should be read an injected in the shared topology only once at upgrade time, but not anymore after. Maybe this calls for adding nodes to the topology tree, if the topology plugin starts and the server is not in the topology tree, then it sources the local configuration, then adds itself and the connections to the topology tree. If the node is already in the topology tree this step is always skipped. I like the idea that the node can add itself and the connection to the topology tree. But this requires that the node database is already initialized (have the same replicageneration than the others nodes). If it is not initialized, it could be done by any masters. But if it is automatic, there is a risk that several masters will want to initialize it. In addition if the new node has a different replicageneration, how does the new node know that it should wait to be initialized rather than initialize the others. Or something similar (could be just a flag in cn=masters objects). makes sense ? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Move replication topology to the shared tree
On Wed, 2014-06-04 at 18:04 +0200, thierry bordaz wrote: On 06/04/2014 05:41 PM, Simo Sorce wrote: On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote: On 06/04/2014 10:43 AM, thierry bordaz wrote: So my proposal would contain the following components 1] Store replication configuration in the shared tree in a combination of server and connection view (think we need both) and map replication configuration to these entries. I would prefer a direct mapping (with a subset of the cn=config attributes and required additions) About adding a new server in the replication topology. If it was initialized, it may register itself into the shared tree and then join the topology. If it was not initialized, it can be initialized online by one of the master. Will it be triggered with an update to the shared tree ? I think this has to be decided, I proposed some kind of bootstrapping: If the topology plugin is enabled and started it would check if there is already info on the connections for this server and if not create/update the entry in the shared tree, this could also happen if a new server is added. You mean updating the shared tree from information about replication agreements found in cn=config ? I can see how this would be useful in migration from previous server versions, but I fear would cause issues if you remove a connection when one of the 2 servers is down. When you bring the server up it would try to re-create a connection that was deleted by the admin. It's a catch-22 which is why I want the shared tree to be authoritative but not the cn=config tree. But Simo wanted to have the info in the shared tree indepndent of what was already configured. It's not much about being independent, it's about what is authoritative and what is not. One problem with the automatic approach is what should be done if the config differs on the already deployed servers That's just one of many problems. I think cn=config entries should be read an injected in the shared topology only once at upgrade time, but not anymore after. Maybe this calls for adding nodes to the topology tree, if the topology plugin starts and the server is not in the topology tree, then it sources the local configuration, then adds itself and the connections to the topology tree. If the node is already in the topology tree this step is always skipped. I like the idea that the node can add itself and the connection to the topology tree. But this requires that the node database is already initialized (have the same replicageneration than the others nodes). If it is not initialized, it could be done by any masters. But if it is automatic, there is a risk that several masters will want to initialize it. In addition if the new node has a different replicageneration, how does the new node know that it should wait to be initialized rather than initialize the others. Yeah see my follow-up, I think a flag would be better, this way import is done only once and never more. If a node is already initialized then the topology plugin will always wipe away and reconfigure agreements in cn=config from the topology tree and never backwards. 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] Is CA certificate storage correct?
On 23.5.2014 16:36, Martin Kosek wrote: On 05/20/2014 11:16 AM, Jan Cholasta wrote: On 20.5.2014 08:28, Martin Kosek wrote: Hi there, I checked the update CA Certificate renewal feature design page and one part seemed awkward to me: http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store IIUC, when there are multiple iterations of a certificate stored, there will be one LDAP object with multiple cACertificate attributes, multiple ipaKeyUsage attributes, ipaKeyTrust, ... Given that LDAP does not guarantee order, how do I identify which cACertificate belongs to which attribute? There is no such relation, ipaKey* attributes apply to all of the cACertificate attributes. If I do ldapsearch for some specific ipaKeyUsage and I get this LDAP record returned, how do I find out which certificate it is? Do I need to go through all binary blobs, parse them and look which blob matches? No. Could you then please state some example in http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store with more than one cACertificate;binary? I think it would greatly help understand the relation of the new schema attributes and cACertificate. As you can see, it may be pretty confusing. Updated the design page. Hopefully it's clearer now. Martin -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] CA certificate renewal, shared store trust settings
On 30.5.2014 16:11, Nalin Dahyabhai wrote: On Fri, May 30, 2014 at 09:09:46AM +0200, Jan Cholasta wrote: On 29.5.2014 19:44, Nalin Dahyabhai wrote: I'm working on adding to certmonger the ability to read the IPA root certificate from the server and store it locally, and I'm looking at the V4 shared certificate store feature [1] with an eye toward also pulling down and processing those certificates. Before I head down that path, I've got a few questions about the schema that the page describes for storing trust information. So, you want to fetch the certificates directly from LDAP? Shouldn't they rather be fetched using IPA API (in ipa-submit) or Dogtag API (in dogtag-ipa-renew-agent-submit)? Yes, that's something the daemon is farming out to the enrollment helpers. As a start, though, I'm only looking at teaching ipa-submit to fetch this information. The IPA interfaces run over HTTPS, so I thought that having ipa-submit search LDAP using GSSAPI would avoid complications that could arise if the CA certificate had become invalid before we went to fetch things. Right, that might be a problem. The request for the read the root certificate functionality is to have something that works against servers running IPA on EL6, so the ability to fetch the v3 root information is dictated by needing to work against what we're already storing and offering there. Accessing the additional information that's coming in v4 could be done differently, but I'd also lean toward looking at the directory directly. The design page mentions asking SSSD for it, which I guess would work. Well, both will work. In the past few months that I worked on the CA certificate renewal feature the shared certificate store design has evolved into something more about certificate trust policy rather than simple storage of CA certificates. My plan is to integrate it with p11-kit in the forthcoming months to provide the policy to IPA clients. SSSD is going to be used as the component between IPA and p11-kit. A PKCS#11 module will be provided for (not only) that. (This is what http://www.freeipa.org/page/V4/CA_certificate_renewal_(2) is going to be about.) I can imagine you might as well talk to the module to fetch the CA certificates. Are there any plans to support PKCS#11 as a storage backend in certmonger? Only notionally, as it it's only ever been one of those would be cool, but we don't need it in the short-term things. I also wasn't looking forward to dealing with cases where a removable token isn't inserted right when we intend to access it, but if we need to make that work, then okay. This does not make me nervous at all. Take a look at other similar attributes in IPA, they all use directory string syntax. I'm open to suggestions, though. The first thing that comes to mind is an enumerated syntax like the one for booleans, but I understand that enforcing that would require help from the server itself. The docs tell me that syntax plugins are a thing we can supply, but that might be more than we want to bite off. My thoughts exactly. The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted' and 'distrusted', appears to map pretty directly to the sort of information that OpenSSL stores in trusted certificates [2], but going through the man pages for x509(1) and verify(1), I don't see anything that obviously corresponds to an ipaKeyTrust value of 'unknown'. What's that value intended to signify, and how would consumers of the certificates be expected to treat certificates from entries with that ipaKeyTrust value? Actually it is designed to map to p11-kit-style trust policy (http://p11-glue.freedesktop.org/doc/storing-trust-policy/index.html), which is a superset of OpenSSL's. What's the planned schedule for teaching NSS and OpenSSL to consume trust information supplied in this format? It's all available in Fedora since F19, see http://fedoraproject.org/wiki/Features/SharedSystemCertificates. The unknown value means the trust is not explicitly given and that if there is other source of trust information for the key/certificate, it should be used. In p11-kit terms, it is for certificates which are neither in the anchors nor the blacklist set. In NSS terms, it's for certificates without any of the C, T, P or p trust flags. Okay, that makes sense -- they're around for building chains, but not much else. Are there examples of what the ipaKeyUsage attribute should contain? It's the purpose bit names from the key usage certificate extension (http://tools.ietf.org/html/rfc5280#section-4.2.1.3) or none. So, enumerated values represented as directory strings? Yes. Is there a recommended method for mapping from this representation to the form that we'd pass to certutil(1)'s '-t' option when storing the certificates in NSS databases, or is the intent that it be translated into NSS-specific PKCS#11 attributes set on those certificates? Well, it can be both. But as I said
[Freeipa-devel] [PATCHES] 0568-0570 Convert User default permissions to managed
Hello,
I try to think about any kind of data the user might have in LDAP, but
in the spirit of YAGNI, I'll deal with the various corner cases in IPA's
historic default permissions as I go along.
Patch 0568 adds support for the case where the default permissions
changed in something else than attribute lists. Needed for the 'Change
User password' permission.
Patch 0569 converts user permissions to managed.
Patch 0570 fixes https://fedorahosted.org/freeipa/ticket/3697
--
Petr³
From a09d3e24805f29a828f67ee4cab3a6f8bbc0e693 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 4 Jun 2014 16:11:30 +0200
Subject: [PATCH] managed perm updater: Handle case where we changed default
ACIs in the past
This handles the case where IPA's default ACIs changed in something else
than just attribute lists.
In this case we can narrow the set of ACIs we think the user might be
upgrading from.
Part of the work for: https://fedorahosted.org/freeipa/ticket/4346
---
.../install/plugins/update_managed_permissions.py| 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py
index 13433d353cd09de77029fd76f7070bf79a432774..e6f852c09d1a732109da5d56320192d4e617ab38 100644
--- a/ipaserver/install/plugins/update_managed_permissions.py
+++ b/ipaserver/install/plugins/update_managed_permissions.py
@@ -408,11 +408,20 @@ def get_upgrade_attr_lists(self, current_acistring, default_acistrings):
An attribute will be included if the user has it in LDAP but it does
not appear in *any* historic ACI.
It will be excluded if it is in *all* historic ACIs but not in LDAP.
+Rationale: When we don't know which version of an ACI the user is
+upgrading from, we only consider attributes where all the versions
+agree. For other attrs we'll use the default from the new managed perm.
If the ACIs differ in something else than the list of attributes,
raise IncompatibleACIModification. This means manual action is needed
(either delete the old permission or change it to resemble the default
-again, then re-run ipa-ldap-updater)
+again, then re-run ipa-ldap-updater).
+
+In case there are multiple historic default ACIs, and some of them
+are compatible with the current but other ones aren't, we deduce that
+the user is upgrading from one of the compatible ones.
+The incompatible ones are removed from consideration, both for
+compatibility and attribute lists.
assert default_acistrings
@@ -434,6 +443,7 @@ def _pop_targetattr(aci):
attrs_in_all_defaults = None
attrs_in_any_defaults = set()
+all_incompatible = True
for default_acistring in default_acistrings:
default_aci = ACI(default_acistring)
default_attrs = _pop_targetattr(default_aci)
@@ -442,7 +452,9 @@ def _pop_targetattr(aci):
if current_aci != default_aci:
self.log.debug('ACIs not compatible')
-raise(IncompatibleACIModification())
+continue
+else:
+all_incompatible = False
if attrs_in_all_defaults is None:
attrs_in_all_defaults = set(default_attrs)
@@ -450,6 +462,10 @@ def _pop_targetattr(aci):
attrs_in_all_defaults = attrs_in_all_defaults
attrs_in_any_defaults |= default_attrs
+if all_incompatible:
+self.log.debug('All old default ACIs are incompatible')
+raise(IncompatibleACIModification())
+
included = current_attrs - attrs_in_any_defaults
excluded = attrs_in_all_defaults - current_attrs
--
1.9.0
From fb01e2a0c9e84ff618b5de01c1373bded154e5d9 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 4 Jun 2014 15:21:26 +0200
Subject: [PATCH] Convert User default permissions to managed
Part of the work for: https://fedorahosted.org/freeipa/ticket/4346
---
install/share/delegation.ldif| 72 ---
install/updates/40-delegation.update | 16 ---
ipalib/plugins/user.py | 84
3 files changed, 84 insertions(+), 88 deletions(-)
diff --git a/install/share/delegation.ldif b/install/share/delegation.ldif
index 43d13974ffd63ea6ee554c815b911715609149b8..2c712bfc174b3151a5bf69e37ebfe58f2fff96f4 100644
--- a/install/share/delegation.ldif
+++ b/install/share/delegation.ldif
@@ -133,65 +133,6 @@ dn: cn=Host Enrollment,cn=privileges,cn=pbac,$SUFFIX
# Default permissions.
-# User administration
-
-dn: cn=Add Users,cn=permissions,cn=pbac,$SUFFIX
-changetype: add
-objectClass: top
-objectClass: groupofnames
-objectClass: ipapermission
-cn: Add Users
-member: cn=User
Re: [Freeipa-devel] User life Cycle: referential integrity
On 06/04/2014 06:02 PM, Simo Sorce wrote: On Wed, 2014-06-04 at 17:46 +0200, thierry bordaz wrote: Hello, I am looking at the appropriate way to configure DS referential integrity and I am hitting some issues about its scoping and which attributes need to be preserved. User A and B are both Active. User A refers user B for example 'owner: DN user B in Active container'. If entry A is deleted (user-del), it keeps 'owner: DN user B in Active container'. Do we really want to preserve such attributes (owner, member, seeAlso...) in case the user is coming back (user-undel) ? No, when a user is deleted all references to it in the rest of the tree should be removed. the entries it references can stay I guess, the user is deleted so no harm should come from it having dangling DNs in its attributes. Actually it was my concern. If users A then B are moved Active-Delete (user-del), then the reference to B in the 'Active' container is not removed by RI. If for any reason user A returns to Active (user-undel), it contains dangling DN unless it is checked/removed. If it makes sense we may achieve this if we extends RI to both 'Active' and 'Delete' container. Nope, makes no sense. If we prefer to remove such attributes, then 'user-del' is a MODRDN followed by some MODs or a ADD-DEL where the Delete entry is rebuilt from the 'Active' entry. Delete must be a modrdn, we cannot delete the entry and re-add it. ok great :) This is a similar problem when using 'stageuser-add id --from-delete', the references may become invalid (unless RI also covers Staging). There should be no references in either staged or delete users, or they should be adjusted when the user is unstaged/undeleted. An option would be to accept to have invalid references in 'staging' and 'delete', but when the entry is stageuser-activate/user-undel the reference are checked and removed if invalid. Here invalid means, the referred entry does not exist or is not 'Active'. Yup, this sounds right, when you activate the user references need to be checked and adjusted accordingly. Which attributes need to be checked/adjusted ? those configured in RI ? attributes with DN syntax ? thierry Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life Cycle: referential integrity
On Wed, 2014-06-04 at 18:46 +0200, thierry bordaz wrote: On 06/04/2014 06:02 PM, Simo Sorce wrote: On Wed, 2014-06-04 at 17:46 +0200, thierry bordaz wrote: Hello, I am looking at the appropriate way to configure DS referential integrity and I am hitting some issues about its scoping and which attributes need to be preserved. User A and B are both Active. User A refers user B for example 'owner: DN user B in Active container'. If entry A is deleted (user-del), it keeps 'owner: DN user B in Active container'. Do we really want to preserve such attributes (owner, member, seeAlso...) in case the user is coming back (user-undel) ? No, when a user is deleted all references to it in the rest of the tree should be removed. the entries it references can stay I guess, the user is deleted so no harm should come from it having dangling DNs in its attributes. Actually it was my concern. If users A then B are moved Active-Delete (user-del), then the reference to B in the 'Active' container is not removed by RI. If for any reason user A returns to Active (user-undel), it contains dangling DN unless it is checked/removed. If it makes sense we may achieve this if we extends RI to both 'Active' and 'Delete' container. Nope, makes no sense. If we prefer to remove such attributes, then 'user-del' is a MODRDN followed by some MODs or a ADD-DEL where the Delete entry is rebuilt from the 'Active' entry. Delete must be a modrdn, we cannot delete the entry and re-add it. ok great :) This is a similar problem when using 'stageuser-add id --from-delete', the references may become invalid (unless RI also covers Staging). There should be no references in either staged or delete users, or they should be adjusted when the user is unstaged/undeleted. An option would be to accept to have invalid references in 'staging' and 'delete', but when the entry is stageuser-activate/user-undel the reference are checked and removed if invalid. Here invalid means, the referred entry does not exist or is not 'Active'. Yup, this sounds right, when you activate the user references need to be checked and adjusted accordingly. Which attributes need to be checked/adjusted ? those configured in RI ? attributes with DN syntax ? Probably all the attrributes with DN syntax, I am partiocularly concerned with memberof and manager. but memberof should be removed automatically at delete time by the fact the user should be removed from any group (does RI do this when an entry moves out of scope ?) Manager if there should probably be adjusted, others should probably be just wiped and let automember or other plugin or an admin fix whatever need fixing ? Seem like a rathole especially if the user has an objectclass in ti the has a DN containing attribute as MUST ... We need to think of a sensible behavior when this happens as it could be an additional custom class/attribute the admin added... 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] Reorganization of Web UI navigation items
On 06/04/2014 05:35 PM, Simo Sorce wrote: On Wed, 2014-06-04 at 08:44 +0200, Martin Kosek wrote: On 06/04/2014 08:34 AM, Martin Kosek wrote: ... Users - Users - Groups - SUDO Hosts - Hosts - Host groups - Services - Netgroups - Automount Authentication - OTP Tokens - Password Policy - Kerberos Ticket Policy Policy - HBAC - SELinux User Maps - Automember Alternatively, we could rename Policy to Authorization as both HBAC and SELinux is about authorizing what an authenticated user can do. We would just need to move Automember to different place, though this one is difficult - it relates both to Users and Hosts, just like Netgroup. I do not see the need to do Policy - Authorization but Automember is in the wrong place imo. The first tab should be Users - Accounts and include automember in it as automember is about groupings ? Actually I would merge the current Users and Hosts tabs into 'Accounts' (or maybe 'Identities' ?) and add Automember. Simo. Automember is about grouping both users and hosts. I put it under Policy originally as it basically is a policy, when are certain users/hosts automember'ed. I would personally not merge Users and Hosts top level menus to one top level menu as that would spoil the whole reason why this effort is done, i.e. have at most 7 items in the second level bar to make things clearer. To me, it seemed a good idea to split Users and Hosts to achieve the target as it separates well the intent what one wants to do. Now we have it all under Identity (including DNS and Realm Domains) which is messy. But I am pretty open to counter-proposals which keeps the UX requirement of 7 second level items. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Reorganization of Web UI navigation items
On Wed, 2014-06-04 at 20:52 +0200, Martin Kosek wrote: On 06/04/2014 05:35 PM, Simo Sorce wrote: On Wed, 2014-06-04 at 08:44 +0200, Martin Kosek wrote: On 06/04/2014 08:34 AM, Martin Kosek wrote: ... Users - Users - Groups - SUDO Hosts - Hosts - Host groups - Services - Netgroups - Automount Authentication - OTP Tokens - Password Policy - Kerberos Ticket Policy Policy - HBAC - SELinux User Maps - Automember Alternatively, we could rename Policy to Authorization as both HBAC and SELinux is about authorizing what an authenticated user can do. We would just need to move Automember to different place, though this one is difficult - it relates both to Users and Hosts, just like Netgroup. I do not see the need to do Policy - Authorization but Automember is in the wrong place imo. The first tab should be Users - Accounts and include automember in it as automember is about groupings ? Actually I would merge the current Users and Hosts tabs into 'Accounts' (or maybe 'Identities' ?) and add Automember. Simo. Automember is about grouping both users and hosts. I put it under Policy originally as it basically is a policy, when are certain users/hosts automember'ed. I would personally not merge Users and Hosts top level menus to one top level menu as that would spoil the whole reason why this effort is done, i.e. have at most 7 items in the second level bar to make things clearer. To me, it seemed a good idea to split Users and Hosts to achieve the target as it separates well the intent what one wants to do. Now we have it all under Identity (including DNS and Realm Domains) which is messy. Unfortunately some of your groupings make little sense to me: - why is SUDO under Users ?? It's a security policy and those policies are equally related to users, groups and hosts. - why policies are under authentication ? Both password policies and Kerberos Ticket policies have nothing to do with the authentication part, but with changing password and with which features are allowed on tickets. - why automember is in Policy ? It is just autoconfiguration it doesn't enforce any policy on its own But I am pretty open to counter-proposals which keeps the UX requirement of 7 second level items. Martin This is how it makes sense to me as a logical grouping: Accounts/Identity (7): - Users - Groups - Hosts - Host Groups - Netgroups - Services - Automember ^ These are all identity or identity-grouping related objects/actions Policies (6): - Sudo - HBAC - SELinux User Maps - OTP Tokens (*) - Password Policies - Kerberos ticket Policies ^ These are all Security Policies an admin cares about Directory (6): - Permissions - Privileges - Roles - Delegation NOTE: the 4 above can be merged into a single 'Authorization' entry perhaps - Replication Topology - Views (future) ^ Everything that deals with direct LDAP access/view Network Services (4): - Automount - DNS - CA - Vault (future) ^ All the additional network services or configuration of network related services Configuration (3): - Trusts - ID Ranges - Realm Domains - Global ^ Anything that does not fit the above categories. Docs: - whatever :) (*) The only doubt I have is about OTP Tokens, it may be worth taking them off Policies and putting them into a new tab which in future may also sport a pointer to user certificates management: Authentication: - OTP Tokens - User Certificates (future) HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0261-0262] Support run-time changes in idnsSecInlineSigning attribute
Hello,
This patch set allows you to change DNSSEC zone configuration at run-time.
--
Petr^2 Spacek
From 080f922b0920105def25f19c28da1d448406ccce Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Wed, 4 Jun 2014 21:25:15 +0200
Subject: [PATCH] Delete old database journal files during zone loading.
This prevents inline-signed zones from failing to receive updates from
LDAP mysteriously.
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 2eb9c4d63d05486799b90ce4d23cf3fb26c6ca17..3a0ac6ddea237fcd74c146bad7400b516422ff27 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -782,12 +782,14 @@ delete_bind_zone(dns_zt_t *zt, dns_zone_t **zonep) {
return result;
}
-isc_result_t
+static isc_result_t ATTR_NONNULLS
cleanup_zone_files(dns_zone_t *zone) {
isc_result_t result;
isc_boolean_t failure = ISC_FALSE;
const char *filename = NULL;
dns_zone_t *raw = NULL;
+ int namelen;
+ char bck_filename[PATH_MAX];
dns_zone_getraw(zone, raw);
if (raw != NULL) {
@@ -804,6 +806,17 @@ cleanup_zone_files(dns_zone_t *zone) {
result = fs_file_remove(filename);
failure = failure || (result != ISC_R_SUCCESS);
+ /* Taken from dns_journal_open() from bind-9.9.4-P2:
+ * Journal backup file name ends with .jbk instead of .jnl. */
+ namelen = strlen(filename);
+ if (namelen 4 strcmp(filename + namelen - 4, .jnl) == 0)
+ namelen -= 4;
+ CHECK(isc_string_printf(bck_filename, sizeof(bck_filename),
+%.*s.jbk, namelen, filename));
+ CHECK(fs_file_remove(bck_filename));
+
+cleanup:
+ failure = failure || (result != ISC_R_SUCCESS);
if (failure == ISC_TRUE)
dns_zone_log(zone, ISC_LOG_ERROR,
unable to remove files, expect problems);
@@ -946,6 +959,7 @@ create_zone(ldap_instance_t * const inst, const char * const dn,
if (want_secure == ISC_FALSE) {
CHECK(dns_zonemgr_managezone(inst-zmgr, raw));
+ CHECK(cleanup_zone_files(raw));
} else {
CHECK(dns_zone_create(secure, inst-mctx));
CHECK(dns_zone_setorigin(secure, name));
@@ -957,6 +971,7 @@ create_zone(ldap_instance_t * const inst, const char * const dn,
CHECK(dns_zone_link(secure, raw));
dns_zone_rekey(secure, ISC_TRUE);
CHECK(configure_paths(inst-mctx, inst, secure, ISC_TRUE));
+ CHECK(cleanup_zone_files(secure));
}
sync_state_get(inst-sctx, sync_state);
--
1.9.3
From d89284fc0aafe001e5ce1599d04dac62f48ad108 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Wed, 4 Jun 2014 22:39:46 +0200
Subject: [PATCH] Support run-time changes in idnsSecInlineSigning attribute.
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c | 92 +
src/zone_register.c | 24 --
src/zone_register.h | 7 ++--
3 files changed, 91 insertions(+), 32 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 3a0ac6ddea237fcd74c146bad7400b516422ff27..deda6955a215441a40857d78273fb8042275385e 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -293,6 +293,11 @@ static isc_result_t parse_rdata(isc_mem_t *mctx, ldap_entry_t *entry,
dns_name_t *origin, const char *rdata_text,
dns_rdata_t **rdatap) ATTR_NONNULLS ATTR_CHECKRESULT;
static isc_result_t
+ldap_parse_master_zoneentry(ldap_entry_t * const entry, dns_db_t * const olddb,
+ ldap_instance_t *const inst,
+ isc_task_t *const task)
+ ATTR_NONNULL(1,3,4) ATTR_CHECKRESULT;
+static isc_result_t
ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry, dns_name_t *origin,
const char *fake_mname, ldapdb_rdatalist_t *rdatalist) ATTR_NONNULLS ATTR_CHECKRESULT;
@@ -926,8 +931,9 @@ cleanup:
*/
static isc_result_t ATTR_NONNULLS ATTR_CHECKRESULT
create_zone(ldap_instance_t * const inst, const char * const dn,
- dns_name_t * const name, const isc_boolean_t want_secure,
- dns_zone_t ** const rawp, dns_zone_t ** const securep)
+ dns_name_t * const name, dns_db_t * const ldapdb,
+ const isc_boolean_t want_secure, dns_zone_t ** const rawp,
+ dns_zone_t ** const securep)
{
isc_result_t result;
dns_zone_t *raw = NULL;
@@ -987,7 +993,7 @@ create_zone(ldap_instance_t * const inst, const char * const dn,
}
}
- CHECK(zr_add_zone(inst-zone_register, raw, secure, dn));
+ CHECK(zr_add_zone(inst-zone_register, ldapdb, raw, secure, dn));
*rawp = raw;
*securep = secure;
@@ -2192,11 +2198,6 @@ zone_sync_apex(const ldap_instance_t * const inst,
* = do nothing. */
}
- /* New zone has to have at least SOA record and NS record. */
- if (new_zone == ISC_TRUE
- (*data_changed == ISC_FALSE || soa_tuple == NULL))
- result = DNS_R_BADZONE;
-
cleanup:
if (soa_tuple_alloc == ISC_TRUE soa_tuple != NULL)
dns_difftuple_free(soa_tuple);
@@ -2208,10 +2209,54 @@
[Freeipa-devel] joining rhel5 ipa clients to rhel 7 server failing caused by time offset.
I was trying to join my rhel 5 client to a rhel 7 domain, and getting the following error: [root@oracle ~]# ipa-client-install -p admin -w pw -U root: ERRORLDAP Error: Connect error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed root: ERRORLDAP Error: Connect error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Unable to find IPA Server to join Installation failed. Rolling back changes. IPA client is not configured on this system. Tried to verify the cert with this: openssl s_client -host iota.testrelm.test -port 443 -CAfile /etc/ipa/ca.crt This came up with this error code: Verify return code: 9 (certificate is not yet valid) After syncing the clock, everything worked al-right. I tried googling around a bit, but I couldn't find any specific articles about this problem. Does this sound like a troubleshooting and repair step that is documented somewhere already? Michael- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] joining rhel5 ipa clients to rhel 7 server failing caused by time offset.
Michael Gregg wrote: I was trying to join my rhel 5 client to a rhel 7 domain, and getting the following error: [root@oracle ~]# ipa-client-install -p admin -w pw -U root: ERRORLDAP Error: Connect error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed root: ERRORLDAP Error: Connect error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Unable to find IPA Server to join Installation failed. Rolling back changes. IPA client is not configured on this system. Tried to verify the cert with this: openssl s_client -host iota.testrelm.test -port 443 -CAfile /etc/ipa/ca.crt This came up with this error code: Verify return code: 9 (certificate is not yet valid) After syncing the clock, everything worked al-right. I tried googling around a bit, but I couldn't find any specific articles about this problem. Does this sound like a troubleshooting and repair step that is documented somewhere already? I don't recall any documentation on this. The time should be synchronized before that happens. Can you send me the full ipaclient-install.log? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] joining rhel5 ipa clients to rhel 7 server failing caused by time offset.
On 06/04/2014 02:07 PM, Rob Crittenden wrote:
Michael Gregg wrote:
I was trying to join my rhel 5 client to a rhel 7 domain, and getting
the following error:
[root@oracle ~]# ipa-client-install -p admin -w pw -U
root: ERRORLDAP Error: Connect error: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
root: ERRORLDAP Error: Connect error: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Unable to find IPA Server to join
Installation failed. Rolling back changes.
IPA client is not configured on this system.
Tried to verify the cert with this:
openssl s_client -host iota.testrelm.test -port 443 -CAfile /etc/ipa/ca.crt
This came up with this error code:
Verify return code: 9 (certificate is not yet valid)
After syncing the clock, everything worked al-right. I tried googling
around a bit, but I couldn't find any specific articles about this problem.
Does this sound like a troubleshooting and repair step that is
documented somewhere already?
I don't recall any documentation on this. The time should be
synchronized before that happens. Can you send me the full
ipaclient-install.log?
rob
Sure thing. The log is not very long. It is attached.
2013-06-04 15:17:38,797 DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': None, 'uninstall': False, 'force': False, 'sssd': True, 'krb5_offline_passwords': True, 'hostname': None, 'permit': False, 'server': None, 'prompt_password': False, 'mkhomedir': False, 'dns_updates': False, 'preserve_sssd': False, 'debug': False, 'on_master': False, 'ca_cert_file': None, 'realm_name': None, 'unattended': True, 'ntp_server': None, 'principal': 'admin'}
2013-06-04 15:17:38,797 DEBUG missing options might be asked for interactively later
2013-06-04 15:17:38,797 DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
2013-06-04 15:17:38,797 DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
2013-06-04 15:17:38,797 DEBUG [IPA Discovery]
2013-06-04 15:17:38,798 DEBUG Starting IPA discovery with domain=None, servers=None, hostname=oracle.testrelm.test
2013-06-04 15:17:38,798 DEBUG [ipadnssearchldap(testrelm.test)]
2013-06-04 15:17:38,799 DEBUG [ipadnssearchkrb]
2013-06-04 15:17:38,801 DEBUG [ipacheckldap]
2013-06-04 15:17:38,802 DEBUG Verifying that gamma.testrelm.test (realm TESTRELM.TEST) is an IPA server
2013-06-04 15:17:38,802 DEBUG Init ldap with: ldap://gamma.testrelm.test:389
2013-06-04 15:17:38,813 ERROR LDAP Error: Connect error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2013-06-04 15:17:38,813 WARNING Skip gamma.testrelm.test: cannot verify if this is an IPA server
2013-06-04 15:17:38,813 DEBUG Verifying that iota.testrelm.test (realm TESTRELM.TEST) is an IPA server
2013-06-04 15:17:38,814 DEBUG Init ldap with: ldap://iota.testrelm.test:389
2013-06-04 15:17:38,816 ERROR LDAP Error: Connect error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2013-06-04 15:17:38,816 WARNING Skip iota.testrelm.test: cannot verify if this is an IPA server
2013-06-04 15:17:38,816 DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=testrelm.test, kdc=iota.testrelm.test,gamma.testrelm.test, basedn=None
2013-06-04 15:17:38,816 DEBUG Validated servers:
2013-06-04 15:17:38,816 DEBUG will use domain: testrelm.test
2013-06-04 15:17:38,817 DEBUG IPA Server not found
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
