[Freeipa-devel] Packaging FreeIPA Foreman smartproxy

[Martin Kosek]

Hello all,

As 4.0 release is slowly approaching I was more thinking about smartproxy
package (freeipa-server-foreman-smartproxy). It is currently part of upstream
git repo and if nothing changes, it would be part of FreeIPA 4.0 core packages.

However, I do not see the Foreman smartproxy as the required part of core
FreeIPA 4.0 with many installation, but rather as a glue plugin (important
one!) between FreeIPA and Foreman that would be installed only on specialized
deployments with Foreman.

The plugin's release will be asynchronous to FreeIPA release process - we do
not want to release FreeIPA core when the smartproxy adds new capability or
calls that Foreman needs and vice versa.

I see 2 options how to more forward:

1) Request a separate repo for foreman proxy on fedorahosted, like
"freeipa-foreman.git" move the plugin there and build&branch&tag it
asynchronously. This is IMO the cleanest solution.

2) Keep the Foreman plugin in FreeIPA tree, update Makefile and spec to move it
to separate SRPM and source somehow merge the plugin and ipa branches.

Feedback or other ideas welcome.

-- 
Martin Kosek 
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] Packaging FreeIPA Foreman smartproxy

[Petr Spacek]

On 18.6.2014 09:33, Martin Kosek wrote:

1) Request a separate repo for foreman proxy on fedorahosted, like
"freeipa-foreman.git" move the plugin there and build&branch&tag it
asynchronously. This is IMO the cleanest solution.

I agree.

--
Petr^2 Spacek

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES 187-201] Improvements and coverage for sudorule plugin

[Petr Viktorin]

On 06/17/2014 12:25 PM, Tomas Babej wrote:


On 05/26/2014 06:20 PM, Petr Viktorin wrote:

On 05/20/2014 06:15 PM, Tomas Babej wrote:

Hi,

the following set of patches fixes:

https://fedorahosted.org/freeipa/ticket/4274
https://fedorahosted.org/freeipa/ticket/4263
https://fedorahosted.org/freeipa/ticket/4324
https://fedorahosted.org/freeipa/ticket/4340
https://fedorahosted.org/freeipa/ticket/4341

and additional minor issues.

The improvemed CI test coverage for the sudorule plugin is added as a
bonus.


You've dropped most of the long commit messages and ticket URLs. Why?



0187: OK



(Speaking of PEP8, if you could remove the baseldap star import from
sudorule.py, it would be great...)



This one did hurt, but the star disappeared.


Thank you, much appreciated.
(Especially the fact that Int is no longer imported from baseldap)


General thoughts:

Would it be possible to merge schema_compat.uldif and
install/updates/10-schema_compat.update into one file? Is the uldif
special somehow? I guess this is a question for Rob.
It would be nice to add a link to some schema-compat-entry-attribute
documentation to these files.


I added Rob to cc. Rob, can you elaborate on this?




0188 - sudorule: Allow using hostmasks for setting allowed hosts


If I run sudorule-add-host / sudorule-remove-host with a hostmask, but 
not host/hostgroup, I get prompted for host and hostgroup. I don't think 
that's the intended behavior.


0189: OK
0190: OK
0191: OK
0192: OK


0193 sudorule: Make sure all the relevant attributes are checked when
setting category to ALL



You're missing the `_` for the hostcategory error message.
Did you think about using something like _("%s cannot be set to 'all'
while there are %s")?


Fixed. Initially, I changed the message as you suggested, but then I
realized, that this might pose a problem for translations that do not
follow the word order in the sentence as it is defined in English language.


Right, sorry for the incorrect example. You can use named substitutions 
for that:
_("can't %(action)s while %(state)s") % {'action': 'move', 'state': 
'asleep'}


One more thing - the function is only called once, could you move it to 
the for loop?


0194: OK
0195: OK
0196-0198: OK
0199-0201: OK

0225:
Looks good. Could you also document the arguments & return value in 
*_external_post_callback docstrings?



--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring

[Petr Viktorin]

On 06/17/2014 02:15 PM, Tomas Babej wrote:


On 06/17/2014 12:03 PM, Timo Aaltonen wrote:

On 17.06.2014 11:16, Martin Kosek wrote:



Attached is a new version of patch 226, and a new patch 228, which moves
the paths from installers to the paths module.


In patch 226, there's another "certificated" typo in 
remove_ca_cert_from_systemwide_ca_store



I greped the repository, and I do not see many paths lurking around any
more, there are only some in the error messages (as these can't be
reliably replaced automatically, and will need some manual love).

If you see any forgotten paths, which should be added to the module, let
me know.



I see another duplicate:
SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d"
SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = 
"/var/lib/sss/pubconf/krb5.include.d/"



Rather than using e.g.
filename = paths.VAR_KERBEROS_KRB5KDC_DIR + file
It would be cleaner to use
filename = os.path.join(paths.VAR_KERBEROS_KRB5KDC_DIR, file)


--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server

[thierry bordaz]

On 06/17/2014 09:42 PM, Simo Sorce wrote:

On Tue, 2014-06-17 at 21:36 +0200, thierry bordaz wrote:

On 06/17/2014 09:29 PM, Simo Sorce wrote:

On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote:

Simo Sorce wrote:

On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote:

* ipa stageuser-add  --from-delete

  It moves a deleted entry to staging container where

  uidNumber: 
  gidNumber: 
  ipaUniqueID: autogenerate (reset to autogenerate)

Why are you resetting the unique id ?

Read back a few in the thread. I suggested, perhaps incorrectly, that
given that there should be no more references to the user once they go
into deleted or staged, it may be ok to reset this value.

Well, let me reiterate, the deleted bucket is for those environments
where they have a mandate (regulation, law, policy, etc..) to never
delete users and reinstate users if they are deleted.
So all uniquely identifying information should be preserved in case the
object is revived. This means we need to do our best to preserve all
these attributes if we can.

This is what is done when an Active user is deleted.
uidNumber/gidNumber/ipaUniqueID are preserved.
When activating a user, currently UUID plugin prevents to set a value.
Should it be relaxed.. I feel not. It is a sensitive info and
provisioning system should not define it.

Why is it sensitive ? A ipaUniqueID is not really sensitive, it just
needs to be unique.


Ok.  I believed it was :-)

I have a concern, if a provisioning system is free to define this value, 
I wonder if it can create problem for replication.
For example a provisioning system creates two staging entries on 
different servers but with the same ipaUniqueID value.
If the entries are activated at the same time, the ADDs operation 
(activation)  will not be replicated because the attribute uniqueness 
plugin will reject it.


This case existed before if two  IPA uuid plugins generated identical 
value on different replica. But the probability was less than if the 
provisioning system is free to set it.





When undelete a user (move Delete->Staging), ipaUniqueID can be
preserved but as the purpose of Staging entry is to become active I
thought it would be better to wipe the value also at this time.

I understand that (and I noted before that I think deleted->staged is a
bad idea IMO :-) ), but you are wiping it only as a workaround, because
the plugin prevents you from adding it. Would have you wiped it if it
were not the case ? And if so, why ?


That is correct. I thought to wipe it because the plugin rejected values 
others than 'autogenerate'.


To relax the control that rejects values other than 'autogenerate', I 
need to modify the plugin. Should it be done under an other ticket or 
can it be part of this RFE ?


thanks
thierry



Simo.




___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] User life-cycle: nsAccountLock

[Martin Kosek]

On 06/17/2014 05:59 PM, thierry bordaz wrote:
> On 06/16/2014 03:04 PM, Rob Crittenden wrote:
...
>Thanks for your precise feedback and sorry for my late answer.
>So if I try to consolidate my understandings, the workflow would be:
> 
> 1. Staging (container: cn=staged
>users,cn=accounts,cn=provisioning,SUFFIX)
>  * ipa stageuser-add 
>It creates a stage entry with
> 
>uidNumber: -1
>gidNumber: -1
>ipaUniqueID: autogenerate
>description: __no_upg__
>manager: checks that the DN is an active user
>nsAccountLock: True

I was thinking about the nsAccountLock part again. Should we really force
provisioning systems to set it to True for staged users? Should we even
manipulate it in stageduser plugin?

The original reason why I proposed it in
http://www.freeipa.org/page/V4/User_Life-Cycle_Management
is to prevent LDAP BINDs on such user or Kerberos authentication on such user.
Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND
pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX?

This would allow us to be sure that nobody can bind/authenticate to these users
without having to manipulate nsAccountLock attribute.

The only downside is that this would not be effective in older FreeIPA
versions, but AFAIR, we specified that if User Life Cycle is enabled, all
server should have at least 4.1 - otherwise for example deleted users would be
put to the special container or old servers would not have the appropriate DS
plugins updates.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0227] sudorule: Allow unsetting sudoorder

[Martin Kosek]

On 06/17/2014 12:27 PM, Tomas Babej wrote:
> Hi,
> 
> After setting sudoorder, you are unable to unset it, since the
> check for uniqueness of order of sudorules is applied incorrectly.
> 
> Fix the behaviour and cover it in the test suite.
> 
> https://fedorahosted.org/freeipa/ticket/4360

ACK. Pushed to master: 637ef11109600d87bfb783eadd4b6401fa58d468

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 667 webui-ci: adjust tests to dns changes

[Petr Vobornik]

All DNS Zone names must be fully qualified.
--
Petr Vobornik
From c5b7d6c24224c999d17a9676627ead7af63a2ea5 Mon Sep 17 00:00:00 2001
From: Petr Vobornik 
Date: Tue, 10 Jun 2014 19:04:49 +0200
Subject: [PATCH] webui-ci: adjust tests to dns changes

All DNS Zone names must be fully qualified.
---
 ipatests/test_webui/test_dns.py  | 2 +-
 ipatests/test_webui/test_host.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ipatests/test_webui/test_dns.py b/ipatests/test_webui/test_dns.py
index c136460ce3bed12112f88668aa5447c6bf72ed97..62f6040a724030e0e9e9c7024a31ef289a8692e2 100644
--- a/ipatests/test_webui/test_dns.py
+++ b/ipatests/test_webui/test_dns.py
@@ -30,7 +30,7 @@ CONFIG_ENTITY = 'dnsconfig'
 
 ZONE_DEFAULT_FACET = 'records'
 
-ZONE_PKEY = 'foo.itest'
+ZONE_PKEY = 'foo.itest.'
 
 ZONE_DATA = {
 'pkey': ZONE_PKEY,
diff --git a/ipatests/test_webui/test_host.py b/ipatests/test_webui/test_host.py
index f5780f868fc21d669de0469879c623836142735d..4b1d4201225e9630993c7116018d5aae5c61ec14 100644
--- a/ipatests/test_webui/test_host.py
+++ b/ipatests/test_webui/test_host.py
@@ -58,7 +58,7 @@ class host_tasks(UI_driver):
 if self.has_dns():
 add_data = [
 ('textbox', 'hostname', host),
-('combobox', 'dnszone', domain),
+('combobox', 'dnszone', domain+'.'),
 ]
 if ip:
 add_data.append(('textbox', 'ip_address', ip))
-- 
1.9.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 668 webui: fix field's default value

[Petr Vobornik]

Fields with default value, such as DNS Zone's idnsforwardpolicy, were
marked as dirty when no value was loaded and when default value of
input control was other than empty.

Fixes regression in DNS Zone details facet - facet is always dirty.
--
Petr Vobornik
From 74d02bbb69433d07851d9c991383de6b3314ebc0 Mon Sep 17 00:00:00 2001
From: Petr Vobornik 
Date: Wed, 18 Jun 2014 12:43:54 +0200
Subject: [PATCH] webui: fix field's default value

Fields with default value, such as DNS Zone's idnsforwardpolicy, were
marked as dirty when no value was loaded and when default value of
input control was other than empty.
---
 install/ui/src/freeipa/field.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/install/ui/src/freeipa/field.js b/install/ui/src/freeipa/field.js
index 24522575da54a3d8e41a80d6fa4a25805074aea5..1ae3ddf3ee98493426a1776f8a315206c5a0f8f6 100644
--- a/install/ui/src/freeipa/field.js
+++ b/install/ui/src/freeipa/field.js
@@ -252,7 +252,7 @@ field.field = IPA.field = function(spec) {
  * Default value
  * @property {Mixed}
  */
-that.default_value = null;
+that.default_value = spec.default_value || null;
 
 /**
  * Field is dirty (value is modified)
-- 
1.9.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 0589 Do not fail if there are multiple nsDS5ReplicaId values in cn=replication, cn=etc

[Petr Viktorin]

https://fedorahosted.org/freeipa/ticket/4375

--
Petr³
From 64315b437a486332b3f9d7fe839c1ac19c58ffb4 Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Thu, 12 Jun 2014 18:07:40 +0200
Subject: [PATCH] Do not fail if there are multiple nsDS5ReplicaId values in
 cn=replication,cn=etc

On systems installed before #3394 was fixed and nsDS5ReplicaId became
single-valued, there are two replica ID values stored in cn=replication:
the default (3) and the actual value we want.
Instead of failing when multiple values are found, use the largest one.

https://fedorahosted.org/freeipa/ticket/4375
---
 ipaserver/install/replication.py | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/ipaserver/install/replication.py b/ipaserver/install/replication.py
index 2805624affc1b559d7474a14b78bb9ad59d27ff6..fbbad5e6c692491ef3d7ba9c8909ce66be1bc624 100644
--- a/ipaserver/install/replication.py
+++ b/ipaserver/install/replication.py
@@ -238,12 +238,17 @@ def _get_replica_id(self, conn, master_conn):
 root_logger.debug("Unable to retrieve nsDS5ReplicaId from remote server")
 raise
 else:
-if replica.single_value.get('nsDS5ReplicaId') is None:
+id_values = replica.get('nsDS5ReplicaId')
+if not id_values:
 root_logger.debug("Unable to retrieve nsDS5ReplicaId from remote server")
 raise RuntimeError("Unable to retrieve nsDS5ReplicaId from remote server")
 
+# nsDS5ReplicaId is single-valued now, but historically it could
+# contain multiple values, of which we need the highest.
+# see bug: https://fedorahosted.org/freeipa/ticket/3394
+retval = max(int(v) for v in id_values)
+
 # Now update the value on the master
-retval = int(replica.single_value['nsDS5ReplicaId'])
 mod = [(ldap.MOD_REPLACE, 'nsDS5ReplicaId', str(retval + 1))]
 
 try:
-- 
1.9.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones

[Martin Basti]

On Fri, 2014-06-13 at 10:28 +0200, Martin Basti wrote:
> Patches attached, require patches mbasti 0052-0055.
> ___
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
Rebased patches attached.
PEP8 fixes.

-- 
Martin^2 Basti

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones

[Martin Basti]

On Wed, 2014-06-18 at 13:44 +0200, Martin Basti wrote:
> On Fri, 2014-06-13 at 10:28 +0200, Martin Basti wrote:
> > Patches attached, require patches mbasti 0052-0055.
> > ___
> > Freeipa-devel mailing list
> > Freeipa-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-devel
> Rebased patches attached.
> PEP8 fixes.
> 
Sorry, patches are here

-- 
Martin^2 Basti
>From 028a43cd15b0d9e8db99b5f403fe627a66b2089a Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Fri, 13 Jun 2014 10:15:23 +0200
Subject: [PATCH 1/2] Added upgrade step executed before schmema is upgraded

Class PreSchemaUpdate is executed before ldap schema update

This is required by ticket: https://fedorahosted.org/freeipa/ticket/3210
---
 ipaserver/install/ipa_ldap_updater.py   | 14 --
 ipaserver/install/ldapupdate.py | 15 ++-
 ipaserver/install/plugins/__init__.py   |  5 +++--
 ipaserver/install/plugins/baseupdate.py | 15 ++-
 ipaserver/install/upgradeinstance.py| 17 +
 5 files changed, 56 insertions(+), 10 deletions(-)

diff --git a/ipaserver/install/ipa_ldap_updater.py b/ipaserver/install/ipa_ldap_updater.py
index e8ef2b576a21f316941260cc00de7910859a9cec..fbbef142a387c6303d773e93be979d46d5f15a5b 100644
--- a/ipaserver/install/ipa_ldap_updater.py
+++ b/ipaserver/install/ipa_ldap_updater.py
@@ -191,12 +191,6 @@ class LDAPUpdater_NonUpgrade(LDAPUpdater):
 
 modified = False
 
-if options.update_schema:
-modified = schemaupdate.update_schema(
-options.schema_files,
-dm_password=self.dirman_password,
-live_run=not options.test) or modified
-
 ld = LDAPUpdate(
 dm_password=self.dirman_password,
 sub_dict={},
@@ -204,6 +198,14 @@ class LDAPUpdater_NonUpgrade(LDAPUpdater):
 ldapi=options.ldapi,
 plugins=options.plugins or self.run_plugins)
 
+modified = ld.pre_schema_update(ordered=True)
+
+if options.update_schema:
+modified = schemaupdate.update_schema(
+options.schema_files,
+dm_password=self.dirman_password,
+live_run=not options.test) or modified
+
 if not self.files:
 self.files = ld.get_all_files(UPDATES_DIR)
 
diff --git a/ipaserver/install/ldapupdate.py b/ipaserver/install/ldapupdate.py
index ecdf8e6e12751dbf472411ec08a3be2bf315c31c..b6c6d2b90b1f86f5d45985d4e1476fd03f7d112d 100644
--- a/ipaserver/install/ldapupdate.py
+++ b/ipaserver/install/ldapupdate.py
@@ -42,7 +42,8 @@ from ipalib import api
 from ipaplatform.paths import paths
 from ipapython.dn import DN
 from ipapython.ipa_log_manager import *
-from ipaserver.install.plugins import PRE_UPDATE, POST_UPDATE
+from ipaserver.install.plugins import (PRE_UPDATE, POST_UPDATE,
+   PRE_SCHEMA_UPDATE)
 from ipaserver.plugins import ldap2
 
 UPDATES_DIR=paths.UPDATES_DIR
@@ -794,6 +795,18 @@ class LDAPUpdate:
 for dn, update in sorted_updates:
 self._delete_record(update)
 
+def pre_schema_update(self, ordered=False):
+"""Execute the update before the LDPA schema is updated.
+"""
+if self.plugins:
+self.info('PRE_SCHEMA_UPDATE')
+all_updates = {}
+updates = api.Backend.updateclient.update(PRE_SCHEMA_UPDATE, self.dm_password, self.ldapi, self.live_run)
+self.merge_updates(all_updates, updates)
+self._run_updates(all_updates)
+
+return self.modified
+
 def update(self, files, ordered=False):
 """Execute the update. files is a list of the update files to use.
 
diff --git a/ipaserver/install/plugins/__init__.py b/ipaserver/install/plugins/__init__.py
index 49bef4df80d9b8ea2f5861dcb69c7ae2fb882472..296831db754b45121b6c7260777c151827a95467 100644
--- a/ipaserver/install/plugins/__init__.py
+++ b/ipaserver/install/plugins/__init__.py
@@ -20,8 +20,9 @@
 """
 Provide a separate api for updates.
 """
-PRE_UPDATE = 1
-POST_UPDATE = 2
+PRE_SCHEMA_UPDATE = 1
+PRE_UPDATE = 2
+POST_UPDATE = 3
 
 FIRST = 1
 MIDDLE = 2
diff --git a/ipaserver/install/plugins/baseupdate.py b/ipaserver/install/plugins/baseupdate.py
index a480a8ee289646374af33f98dcf1f6978a969aa5..dc6672ac5b1edeb4147686d1b05d9bf5d66f68b7 100644
--- a/ipaserver/install/plugins/baseupdate.py
+++ b/ipaserver/install/plugins/baseupdate.py
@@ -20,7 +20,8 @@
 from ipalib import api
 from ipalib import Updater, Object
 from ipaserver.install import service
-from ipaserver.install.plugins import PRE_UPDATE, POST_UPDATE, MIDDLE
+from ipaserver.install.plugins import (PRE_UPDATE, POST_UPDATE,
+   PRE_SCHEMA_UPDATE, MIDDLE)
 
 class DSRestart(service.Service):
 """
@@ -55,6 +56,18 @@ class update(Object):
 
 api.register(update)
 
+
+class PreSchemaUpdate(Updater):
+"""
+Base class for updates that run 

Re: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed

[Martin Kosek]

On 06/16/2014 05:43 PM, Petr Viktorin wrote:
> On 06/13/2014 05:25 PM, Petr Viktorin wrote:
>>
>> With the first patch, old SYSTEM permissions can be replaced. The "Read
>> DNS Entries" did not have an associated ACI, but was rather rolled into
>> a single ACI with the managedBy rule used for per-zone access.
>> (and before that it was part of a deny rule.)
>> We can't remove this permission in an update file, because we need to
>> check that it is indeed an old SYSTEM perm and not a new one with the
>> same name.
>>
>>
>> The second patch converts DNS permissions to managed.
>>
>> The ACIs are put directly in $SUFFIX, because the cn=dns subtree does
>> not exist in all installations.
>>
>> I hope to change this for https://fedorahosted.org/freeipa/ticket/4058,
>> when I've thought more about relationships between plugins, packages,
>> install options, and the updater.
> 
> Testing more, I found a benign bug: the updater complained if the cn=dns
> container was missing. Fixed here.
> 
> Also, the update_dns_permissions plugin is now now obsolete, the third patch
> removes it.
> 

583.2: OK

584.2:

1) Typo in description:
Convewrt the existing default permissions.

2) What would you like to do with per-zone permissions?

# ipa dnszone-add-permission example.com
--
Added system permission "Manage DNS zone example.com."
--
  Manage DNS zone example.com.

# ipa permission-show 'Manage DNS zone example.com.'
  Permission name: Manage DNS zone example.com.
  Granted to Privilege: test2
  Indirect Member of roles: test2

Should the command be converted to add V2 permissions? We would have to also
deal with conversion from old DNS zone permissions to permissionsv2 though.

3) How difficult would it be to also convert "Add/Read/Remove/Update DNS
entries in a zone" permissions to managed? It would make their maintenance and
updates much easier, we would also get rid of more updates in update files.

The only problem I see is how to define 'userattr =
"parent[0,1].managedby#GROUPDN"' in the managed permission, IMO it could be
rough at the moment.

Otherwise the changes worked fine, thanks!

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH 0069] Missing dependency in BUILD.txt

[Martin Basti]

Patch attached
-- 
Martin^2 Basti
>From 097e2d582cfedf1e8de5015a7a9f3c4fb919e9c4 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Fri, 6 Jun 2014 18:02:11 +0200
Subject: [PATCH] Missing dependency in BUILD.txt

---
 BUILD.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BUILD.txt b/BUILD.txt
index 62cbbd95b123128e978ad25907ba4d67ded1ffd4..e445217515ed44db4ad673b7dd9b814bb47f882f 100644
--- a/BUILD.txt
+++ b/BUILD.txt
@@ -7,7 +7,7 @@ The quickest way to get the dependencies needed for building is:
 
 # yum install rpm-build `grep "^BuildRequires" freeipa.spec.in | awk '{ print $2 }' | grep -v "^/"`
 
-This is currently (2014-02-11):
+This is currently (2014-06-06):
 
 yum install rpm-build 389-ds-base-devel svrcore-devel policycoreutils \
 systemd-units samba-devel samba-python libwbclient-devel samba4-devel \
@@ -19,7 +19,7 @@ python-netaddr python-kerberos python-rhsm pyOpenSSL pylint python-polib \
 libipa_hbac-python python-memcached sssd python-lxml python-pyasn1 \
 python-qrcode python-dns m2crypto check libsss_idmap-devel \
 libsss_nss_idmap-devel java-1.7.0-openjdk libverto-devel systemd \
-libunistring-devel python-lesscpy
+libunistring-devel python-lesscpy python-cherrypy
 
 Building
 
-- 
1.8.3.1

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile

[Jan Cholasta]

On 16.6.2014 16:08, Martin Kosek wrote:

On 06/16/2014 02:57 PM, Jan Cholasta wrote:

On 16.6.2014 13:31, Martin Kosek wrote:

On 06/11/2014 02:59 PM, Jan Cholasta wrote:

On 11.6.2014 13:29, Martin Kosek wrote:

On 06/11/2014 10:58 AM, Jan Cholasta wrote:

On 10.6.2014 09:55, Martin Kosek wrote:

On 06/06/2014 12:50 PM, Jan Cholasta wrote:

On 23.1.2014 14:34, Jan Cholasta wrote:

On 22.1.2014 16:43, Simo Sorce wrote:

On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote:

On 22.1.2014 15:34, Simo Sorce wrote:

On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote:

On 21.1.2014 17:12, Simo Sorce wrote:

Later in the patch you seem to be changing from needing
managedby_host
to needing write access to an entry, I am not sure I understand
why that
was changed. not saying it is necessarily wrong,  but why the
original
check is not right anymore ?


The original check is wrong, see
.

The check in my patch allows SAN only if the requesting host has write
access to all of the SAN services. I'm not entirely sure if this is
right, but even if it is not, I think we should still check for write
access to the SAN services, so that access control can be (partially)
handled by ACIs.


Right, I remembered that comment, but it just says to check the right
object's managed-by, here instead you changed it to check if you can
write the usercertificate.

I guess it is the same *if* there is an ACI that gives write permission
when the host is in the managed-by attribute, is that the reasoning ?


Exactly. The ACIs that allow this by default are named "Hosts can manage
service Certificates and kerberos keys" and "Hosts can manage other host
Certificates and kerberos keys".

I think the check can be extended to users as well, so that requesting
certificate with SAN is allowed only to users which have write access to
the SAN services.


I have done the modification, see attached patches.



Sounds good to me then, thanks for explaining.

The patches also look good, but I would like someone to give them a try
for a formal ack.


OK, thanks.



Bump.

I have added stricter validation of subject alt names as well as
certificate
extensions in general to the second patch.


Thanks!


Updated patches attached.

Note that you will need python-nss 0.15 in order to test, you can get a
RPM for
Fedora here: .


John, do you think we could build python-nss 0.15 also for Fedora 20? The
fix
incorporated in it is pretty important to warrant bugfix update in bodhi. It
would also allow FreeIPA 4.0 to be installed on Fedora 20.


Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not
work,
because .


This worked for me, I suspect this is a DS bug. More info in the ticket.

Now back to review of the patch:

210.4: looks ok
234.4:

1) Virtual operation "request certificate with subjectaltname" should be a
member of Certificate Administrators privilege


OK.




2) I would write "Request Certificate With SubjectAltName" with "with"
instead
of "With". I.e.:
Request Certificate with SubjectAltName


OK.




3) Why is the extension check only enforced for non-hosts?

+if not bind_principal.startswith('host/'):
+for ext in extensions:
+operation = self._allowed_extensions.get(ext)
+if operation:
+self.check_access(operation)

My tricky certmonger request passed:

# ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g
2048 -r
-N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D
test2.example.com
-E mko...@redhat.com

while when I posted the same CSR as privileged user, it was rejected:

$ klist
Ticket cache: KEYRING:persistent:96203:96203
Default principal: f...@idm.lab.eng.brq.redhat.com

$ ipa cert-request --principal test/`hostname` certmonger.csr
ipa: ERROR: invalid 'csr': subject alt name type RFC822 Name is forbidden


Right, I meant to NACK myself, but you were faster. Fixed.




4) Regular users cannot read Virtual Operations, so even if I assign them a
permission, command is refused:

$ ipa cert-request --principal test/`hostname` openssl.csr
ipa: ERROR: Insufficient access: No such virtual command

I think we will need to create new managed permission "Read Virtual
Operations"
and assign it to "Certificate Administrators" privilege by default as this
privilege has the virtual operation permissions assigned. Petr3, what is
your
take on this?

Otherwise the patch worked well for me, the authorization part looked OK. My
biggest concern was just the host/user differentiation wrt unknown
subjectaltname types.

Martin



Updated patches attached.



1) I could not compile the patch set:

$ make rpms
...
if [ "" != "yes" ]; then \
  ./makeapi --validate; \
  ./makeaci --validate; \
fi
Traceback (most recent call last):
 File "./makeapi", line 457, in 

Re: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed

[Petr Viktorin]

On 06/18/2014 02:05 PM, Martin Kosek wrote:

On 06/16/2014 05:43 PM, Petr Viktorin wrote:

On 06/13/2014 05:25 PM, Petr Viktorin wrote:


With the first patch, old SYSTEM permissions can be replaced. The "Read
DNS Entries" did not have an associated ACI, but was rather rolled into
a single ACI with the managedBy rule used for per-zone access.
(and before that it was part of a deny rule.)
We can't remove this permission in an update file, because we need to
check that it is indeed an old SYSTEM perm and not a new one with the
same name.


The second patch converts DNS permissions to managed.

The ACIs are put directly in $SUFFIX, because the cn=dns subtree does
not exist in all installations.

I hope to change this for https://fedorahosted.org/freeipa/ticket/4058,
when I've thought more about relationships between plugins, packages,
install options, and the updater.


Testing more, I found a benign bug: the updater complained if the cn=dns
container was missing. Fixed here.

Also, the update_dns_permissions plugin is now now obsolete, the third patch
removes it.



583.2: OK

584.2:

1) Typo in description:
Convewrt the existing default permissions.


Thanks for the catch, I'll fix it before pushing.



2) What would you like to do with per-zone permissions?

# ipa dnszone-add-permission example.com
--
Added system permission "Manage DNS zone example.com."
--
   Manage DNS zone example.com.

# ipa permission-show 'Manage DNS zone example.com.'
   Permission name: Manage DNS zone example.com.
   Granted to Privilege: test2
   Indirect Member of roles: test2

Should the command be converted to add V2 permissions? We would have to also
deal with conversion from old DNS zone permissions to permissionsv2 though.

3) How difficult would it be to also convert "Add/Read/Remove/Update DNS
entries in a zone" permissions to managed? It would make their maintenance and
updates much easier, we would also get rid of more updates in update files.

The only problem I see is how to define 'userattr =
"parent[0,1].managedby#GROUPDN"' in the managed permission, IMO it could be
rough at the moment.


I'd like to leave these two cases until after the "regular" default 
permissions are done.
The regular permissions must be converted now because when you "touch" 
them with 4.0 permission-mod, they get converted to V2 and the updater 
will no longer count them as old default permissions. So we need to 
convert all of them right now. The SYSTEM ones can't be modified so they 
could theoretically wait till 4.1+.
There'll be a few more SYSTEM permissions to convert like 'Modify DNA 
Range'.


For the second case, yes, adding more bind rule types will need some 
work (and a new permission flag). I'd like to combine that work with the 
selfservice/delegation, which also need special bind rules.




Otherwise the changes worked fine, thanks!

Martin




--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed

[Martin Kosek]

On 06/18/2014 02:20 PM, Petr Viktorin wrote:
> On 06/18/2014 02:05 PM, Martin Kosek wrote:
>> On 06/16/2014 05:43 PM, Petr Viktorin wrote:
>>> On 06/13/2014 05:25 PM, Petr Viktorin wrote:

 With the first patch, old SYSTEM permissions can be replaced. The "Read
 DNS Entries" did not have an associated ACI, but was rather rolled into
 a single ACI with the managedBy rule used for per-zone access.
 (and before that it was part of a deny rule.)
 We can't remove this permission in an update file, because we need to
 check that it is indeed an old SYSTEM perm and not a new one with the
 same name.


 The second patch converts DNS permissions to managed.

 The ACIs are put directly in $SUFFIX, because the cn=dns subtree does
 not exist in all installations.

 I hope to change this for https://fedorahosted.org/freeipa/ticket/4058,
 when I've thought more about relationships between plugins, packages,
 install options, and the updater.
>>>
>>> Testing more, I found a benign bug: the updater complained if the cn=dns
>>> container was missing. Fixed here.
>>>
>>> Also, the update_dns_permissions plugin is now now obsolete, the third patch
>>> removes it.
>>>
>>
>> 583.2: OK
>>
>> 584.2:
>>
>> 1) Typo in description:
>> Convewrt the existing default permissions.
> 
> Thanks for the catch, I'll fix it before pushing.
> 
>>
>> 2) What would you like to do with per-zone permissions?
>>
>> # ipa dnszone-add-permission example.com
>> --
>> Added system permission "Manage DNS zone example.com."
>> --
>>Manage DNS zone example.com.
>>
>> # ipa permission-show 'Manage DNS zone example.com.'
>>Permission name: Manage DNS zone example.com.
>>Granted to Privilege: test2
>>Indirect Member of roles: test2
>>
>> Should the command be converted to add V2 permissions? We would have to also
>> deal with conversion from old DNS zone permissions to permissionsv2 though.
>>
>> 3) How difficult would it be to also convert "Add/Read/Remove/Update DNS
>> entries in a zone" permissions to managed? It would make their maintenance 
>> and
>> updates much easier, we would also get rid of more updates in update files.
>>
>> The only problem I see is how to define 'userattr =
>> "parent[0,1].managedby#GROUPDN"' in the managed permission, IMO it could be
>> rough at the moment.
> 
> I'd like to leave these two cases until after the "regular" default 
> permissions
> are done.
> The regular permissions must be converted now because when you "touch" them
> with 4.0 permission-mod, they get converted to V2 and the updater will no
> longer count them as old default permissions. So we need to convert all of 
> them
> right now. The SYSTEM ones can't be modified so they could theoretically wait
> till 4.1+.
> There'll be a few more SYSTEM permissions to convert like 'Modify DNA Range'.

Ok, not a blocker.

> For the second case, yes, adding more bind rule types will need some work (and
> a new permission flag). I'd like to combine that work with the
> selfservice/delegation, which also need special bind rules.

Ok, please make sure that we have the ideas and missing TODOs reflected in 
tickets.

Given these arrangements, ACK to the patch set as is (with the typo fix).

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin

[Ade Lee]

I have not addressed Rob's comments here yet, but will do so in a later
patch.  We are most likely a couple weeks or so away from landing these
patches and we can work on rejiggering/squashing them then.

To help folks review the patches without getting merge issues, and so
that I don't have to worry about rebases until we get closer to the time
we want to commit these patches, I have exposed a repo with the patches
committed so reviewers can pull the patches, or start to work with them.

This is what Endi did to pull my patches:

$ git remote add vakwetu 
git://fedorapeople.org/home/fedora/vakwetu/public_git/freeipa.git
$ git checkout -b alee_0414_drm_add vakwetu/alee_0414_drm_add

Note that there is a change which I am currently designing to provide a
top level baseDN which will affect these patches.

Ade

On Thu, 2014-05-29 at 11:15 -0400, Rob Crittenden wrote:
> Petr Viktorin wrote:
> > On 05/28/2014 08:48 AM, Fraser Tweedale wrote:
> >> On Tue, May 27, 2014 at 05:57:40PM -0400, Ade Lee wrote:
> >>> There have been a couple of changes in the Dogtag interface, that
> >>> require some changes in the IPA patches.  Also, I had to add back a
> >>> function in order to rebase to the latest IPA code.
> >>>
> >>> Most are the patches are as before, attached to this email by default.
> >>>
> >>> The latest Dogtag 10.2 build with the relevant changes needed to work
> >>> with these patches is at:
> >>> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/
> >>>
> >>> Ade
> >>>
> >>
> >> ACK.
> >>
> >> ipa-server-install worked fine for me, and the formatting changes
> >> seem good.  Patch 0003 did not apply cleanly on master (due to minor
> >> conflict in 71c6d2f:installutils.py); an updated patch 0003 is
> >> attached.
> > 
> > Hello,
> > If you do a rebase, could you attach all the patches again?
> > I don't have the Git objects that result from the original patch, so
> > `git am` fails on the later patches:
> > 
> > $ git am -3 *.patch
> > Applying: Add a DRM to IPA
> > Applying: Added ipa-drm-install
> > Applying: Fix various pep 8 issues and comments from review
> > Applying: Added nolog to pkispawn and some additional fixes from review.
> > Applying: Added dogtag plugin for DRM
> > Applying: set drm to not install by default with ipa-server-install
> > Applying: Allow ipa-replica-install to be used for installing replicas
> > error: invalid object 100755 0385a823baa971b0e08d1d93d7409b7a7716e33b
> > for 'install/tools/ipa-replica-install'
> > fatal: git-write-tree: error building trees
> > Repository lacks necessary blobs to fall back on 3-way merge.
> > Cannot fall back to three-way merge.
> > Patch failed at 0007 Allow ipa-replica-install to be used for installing
> > replicas
> > The copy of the patch that failed is found in:
> >/home/pviktori/freeipa/.git/rebase-apply/patch
> > When you have resolved this problem, run "git am --continue".
> > If you prefer to skip this patch, run "git am --skip" instead.
> > To restore the original branch and stop patching, run "git am --abort".
> > 
> 
> I needed to rebase patche 9 as well as it contained a duplicate
> function, check_entropy. No need to rebase it again yet as we have to
> wait to push these until after a future branch anyway.
> 
> Speaking of patch 9, it appears to be all formatting and spelling fixes,
> not all related to the DRM. Patch 4 does similar work. If we're going to
> commit these all separately anyway, is it worthwhile to combine these
> two? Something (or someone) is mighty picky about thru vs through too :-)
> 
> The DRM patches should all have a ticket referenced. At a minimum the
> first one (0002 in this case).
> 
> I think 0007 can be rebased into an existing patch unless we want to
> record in history that the default stance changed.
> 
> Found a place that needs a change. The script
> install/restart_scripts/renew_ca_cert handles fixing the trust on the
> audit cert after renewal. This needs to update the DRM audit cert trust
> as well. Be aware that Honza is making significant changes to this area.
> 
> Otherwise looks ok to me. I'm not super-firm on squashing some of the
> patches, I just don't know what historical benefit might be gained from
> keeping them separate.
> 
> rob
> 
> ___
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed

[Petr Viktorin]

On 06/18/2014 02:23 PM, Martin Kosek wrote:

On 06/18/2014 02:20 PM, Petr Viktorin wrote:

On 06/18/2014 02:05 PM, Martin Kosek wrote:

[...]

583.2: OK

584.2:

1) Typo in description:
Convewrt the existing default permissions.


Thanks for the catch, I'll fix it before pushing.



2) What would you like to do with per-zone permissions?

# ipa dnszone-add-permission example.com
--
Added system permission "Manage DNS zone example.com."
--
Manage DNS zone example.com.

# ipa permission-show 'Manage DNS zone example.com.'
Permission name: Manage DNS zone example.com.
Granted to Privilege: test2
Indirect Member of roles: test2

Should the command be converted to add V2 permissions? We would have to also
deal with conversion from old DNS zone permissions to permissionsv2 though.

3) How difficult would it be to also convert "Add/Read/Remove/Update DNS
entries in a zone" permissions to managed? It would make their maintenance and
updates much easier, we would also get rid of more updates in update files.

The only problem I see is how to define 'userattr =
"parent[0,1].managedby#GROUPDN"' in the managed permission, IMO it could be
rough at the moment.


I'd like to leave these two cases until after the "regular" default permissions
are done.
The regular permissions must be converted now because when you "touch" them
with 4.0 permission-mod, they get converted to V2 and the updater will no
longer count them as old default permissions. So we need to convert all of them
right now. The SYSTEM ones can't be modified so they could theoretically wait
till 4.1+.
There'll be a few more SYSTEM permissions to convert like 'Modify DNA Range'.


Ok, not a blocker.


I opened [#4384] for 1).


For the second case, yes, adding more bind rule types will need some work (and
a new permission flag). I'd like to combine that work with the
selfservice/delegation, which also need special bind rules.


Ok, please make sure that we have the ideas and missing TODOs reflected in 
tickets.


I'm tracking 3) as part of [#4346] now. These show up in a simple grep 
or ldapsearch.



Given these arrangements, ACK to the patch set as is (with the typo fix).

Martin



Thanks, pushed to master: 700ac6c11627137db758ad376c44745db579dc84



[#4384] https://fedorahosted.org/freeipa/ticket/4384
[#4346] https://fedorahosted.org/freeipa/ticket/4346

--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed

[Petr Viktorin]

On 06/18/2014 02:23 PM, Martin Kosek wrote:

On 06/18/2014 02:20 PM, Petr Viktorin wrote:

On 06/18/2014 02:05 PM, Martin Kosek wrote:

[...]

583.2: OK

584.2:

1) Typo in description:
Convewrt the existing default permissions.


Thanks for the catch, I'll fix it before pushing.



2) What would you like to do with per-zone permissions?

# ipa dnszone-add-permission example.com
--
Added system permission "Manage DNS zone example.com."
--
Manage DNS zone example.com.

# ipa permission-show 'Manage DNS zone example.com.'
Permission name: Manage DNS zone example.com.
Granted to Privilege: test2
Indirect Member of roles: test2

Should the command be converted to add V2 permissions? We would have to also
deal with conversion from old DNS zone permissions to permissionsv2 though.

3) How difficult would it be to also convert "Add/Read/Remove/Update DNS
entries in a zone" permissions to managed? It would make their maintenance and
updates much easier, we would also get rid of more updates in update files.

The only problem I see is how to define 'userattr =
"parent[0,1].managedby#GROUPDN"' in the managed permission, IMO it could be
rough at the moment.


I'd like to leave these two cases until after the "regular" default permissions
are done.
The regular permissions must be converted now because when you "touch" them
with 4.0 permission-mod, they get converted to V2 and the updater will no
longer count them as old default permissions. So we need to convert all of them
right now. The SYSTEM ones can't be modified so they could theoretically wait
till 4.1+.
There'll be a few more SYSTEM permissions to convert like 'Modify DNA Range'.


Ok, not a blocker.


I opened [#4384] for 1).


For the second case, yes, adding more bind rule types will need some work (and
a new permission flag). I'd like to combine that work with the
selfservice/delegation, which also need special bind rules.


Ok, please make sure that we have the ideas and missing TODOs reflected in 
tickets.


I'm tracking 3) as part of [#4346] now. These show up in a simple grep 
or ldapsearch.



Given these arrangements, ACK to the patch set as is (with the typo fix).

Martin



Thanks, pushed to master: 700ac6c11627137db758ad376c44745db579dc84



[#4384] https://fedorahosted.org/freeipa/ticket/4384
[#4346] https://fedorahosted.org/freeipa/ticket/4346

--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 0585-0587 Convert Password Policy & COSTemplate default permissions to managed

[Martin Kosek]

On 06/13/2014 06:03 PM, Petr Viktorin wrote:
> The first patch is preparation.
> 
> As for the second two, this is how the bulk of the transition will look.

Works fine, also tested with unit test. When testing it, I found one error:

# ipa pwpolicy-add ipausers --maxlife 90 --minlife 1 --priority 1
ipa: ERROR: no such entry

However, this is not a problem in pwpolicy permissions, but rather caused by
https://fedorahosted.org/freeipa/ticket/4372
as ipausers is not readable to the privileged user even though the user has
Group Administrators privilege.

ACK to this patch set (I wanted to push myself, but you just cause a conflict :)

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 0585-0587 Convert Password Policy & COSTemplate default permissions to managed

[Petr Viktorin]

On 06/18/2014 02:48 PM, Martin Kosek wrote:

On 06/13/2014 06:03 PM, Petr Viktorin wrote:

The first patch is preparation.

As for the second two, this is how the bulk of the transition will look.


Works fine, also tested with unit test. When testing it, I found one error:

# ipa pwpolicy-add ipausers --maxlife 90 --minlife 1 --priority 1
ipa: ERROR: no such entry

However, this is not a problem in pwpolicy permissions, but rather caused by
https://fedorahosted.org/freeipa/ticket/4372
as ipausers is not readable to the privileged user even though the user has
Group Administrators privilege.

ACK to this patch set (I wanted to push myself, but you just cause a conflict :)


Thanks for the review!



--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 0578-0579 Convert Host default permissions to managed

[Petr Viktorin]

On 06/11/2014 06:39 PM, Petr Viktorin wrote:

Patch 0578 does the conversion

Patch 0579 fixes https://fedorahosted.org/freeipa/ticket/4252 and
provides permissions needed for automatic enrollment (from
http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser)


Rebasing to current master.


--
Petr³
From fc3a52654df1b37146c28a14ddbc78c5cb5693df Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Fri, 30 May 2014 18:35:31 +0200
Subject: [PATCH] Convert Host default permissions to managed

Part of the work for: https://fedorahosted.org/freeipa/ticket/4346
---
 ACI.txt  | 14 ++
 install/share/delegation.ldif| 82 
 install/updates/40-delegation.update | 29 +
 ipalib/plugins/host.py   | 66 +
 4 files changed, 81 insertions(+), 110 deletions(-)

diff --git a/ACI.txt b/ACI.txt
index cd19fb90fdd0ac1947393aabfd667e46a6f015fc..6d4d2ff5b5be461399505e5b138df53fc3234892 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -38,10 +38,24 @@ dn: cn=System: Read HBAC Services,cn=permissions,cn=pbac,dc=ipa,dc=example
 aci: (targetattr = "cn || description || ipauniqueid || memberof || objectclass")(targetfilter = "(objectclass=ipahbacservice)")(version 3.0;acl "permission:System: Read HBAC Services";allow (compare,read,search) userdn = "ldap:///all";;)
 dn: cn=System: Read HBAC Service Groups,cn=permissions,cn=pbac,dc=ipa,dc=example
 aci: (targetattr = "businesscategory || cn || description || ipauniqueid || member || memberhost || memberuser || o || objectclass || ou || owner || seealso")(targetfilter = "(objectclass=ipahbacservicegroup)")(version 3.0;acl "permission:System: Read HBAC Service Groups";allow (compare,read,search) userdn = "ldap:///all";;)
+dn: cn=System: Add Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add Hosts";allow (add) groupdn = "ldap:///cn=System: Add Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+dn: cn=System: Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetattr = "krbprincipalname")(targetfilter = "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version 3.0;acl "permission:System: Add krbPrincipalName to a host";allow (write) groupdn = "ldap:///cn=System: Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+dn: cn=System: Enroll a host,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetattr = "objectclass")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Enroll a host";allow (write) groupdn = "ldap:///cn=System: Enroll a host,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+dn: cn=System: Manage Host SSH Public Keys,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetattr = "ipasshpubkey")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host SSH Public Keys";allow (write) groupdn = "ldap:///cn=System: Manage Host SSH Public Keys,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+dn: cn=System: Manage host keytab,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetattr = "krblastpwdchange || krbprincipalkey")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage host keytab";allow (write) groupdn = "ldap:///cn=System: Manage host keytab,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+dn: cn=System: Modify Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetattr = "description || l || nshardwareplatform || nshostlocation || nsosversion")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Modify Hosts";allow (write) groupdn = "ldap:///cn=System: Modify Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=System: Read Host Membership,cn=permissions,cn=pbac,dc=ipa,dc=example
 aci: (targetattr = "memberof")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Read Host Membership";allow (compare,read,search) userdn = "ldap:///all";;)
 dn: cn=System: Read Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example
 aci: (targetattr = "cn || description || enrolledby || fqdn || ipaclientversion || ipakrbauthzdata || ipasshpubkey || ipauniqueid || krbcanonicalname || krblastpwdchange || krbpasswordexpiration || krbprincipalaliases || krbprincipalexpiration || krbprincipalname || l || macaddress || managedby || nshardwareplatform || nshostlocation || nsosversion || objectclass || serverhostname || usercertificate || userclass")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Read Hosts";allow (compare,read,search) userdn = "ldap:///all";;)
+dn: cn=System: Remove Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Remove Hosts";allow (delete) groupdn = "ldap:///cn=System: Remove Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=System: Read Hostgroup Membership,cn=permissions,cn=pbac,dc=ipa,

Re: [Freeipa-devel] User life-cycle: nsAccountLock

[thierry bordaz]

On 06/18/2014 12:47 PM, Martin Kosek wrote:

On 06/17/2014 05:59 PM, thierry bordaz wrote:

On 06/16/2014 03:04 PM, Rob Crittenden wrote:

...

Thanks for your precise feedback and sorry for my late answer.
So if I try to consolidate my understandings, the workflow would be:

 1. Staging (container: cn=staged
users,cn=accounts,cn=provisioning,SUFFIX)
  * ipa stageuser-add 
It creates a stage entry with

uidNumber: -1
gidNumber: -1
ipaUniqueID: autogenerate
description: __no_upg__
manager: checks that the DN is an active user
nsAccountLock: True

I was thinking about the nsAccountLock part again. Should we really force
provisioning systems to set it to True for staged users? Should we even
manipulate it in stageduser plugin?


That is correct, provisioning system can create entries in Staging area 
without nsAccountLock or with nsAccountLock: False.
With stageuser-add we have this ability but as you described below it 
can be done with different ways.


We may create a new DS plugin to enforce added stage entries (or 
modifications) have the expected values. But I think the idea was to 
make Stage container free to receive any kind of entries. This was the 
activation job to make the control.


activation (stageuser-activate) is setting 'nsAccountLock: False' so 
currently at least this method is manipulating nsAccountLock.





The original reason why I proposed it in
http://www.freeipa.org/page/V4/User_Life-Cycle_Management
is to prevent LDAP BINDs on such user or Kerberos authentication on such user.
Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND
pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX?
Sure this solution would also have the advantages to prevent 
authentication from Staging/Delete container and allow authentication 
only from 'Active' container.

For LDAP BIND pre-bind which plugin are you thinking of ? a new one ?

About Kerberos update, my understanding is that if we restrict (in sasl 
mapping) the baseDN template (nsSaslMapBaseDNTemplate) to 
cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication 
only to Active user. Is that correct ?




This would allow us to be sure that nobody can bind/authenticate to these users
without having to manipulate nsAccountLock attribute.

The only downside is that this would not be effective in older FreeIPA
versions, but AFAIR, we specified that if User Life Cycle is enabled, all
server should have at least 4.1 - otherwise for example deleted users would be
put to the special container or old servers would not have the appropriate DS
plugins updates.

Martin


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User life-cycle: nsAccountLock

[Simo Sorce]

On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote:
> On 06/17/2014 05:59 PM, thierry bordaz wrote:
> > On 06/16/2014 03:04 PM, Rob Crittenden wrote:
> ...
> >Thanks for your precise feedback and sorry for my late answer.
> >So if I try to consolidate my understandings, the workflow would be:
> > 
> > 1. Staging (container: cn=staged
> >users,cn=accounts,cn=provisioning,SUFFIX)
> >  * ipa stageuser-add 
> >It creates a stage entry with
> > 
> >uidNumber: -1
> >gidNumber: -1
> >ipaUniqueID: autogenerate
> >description: __no_upg__
> >manager: checks that the DN is an active user
> >nsAccountLock: True
> 
> I was thinking about the nsAccountLock part again. Should we really force
> provisioning systems to set it to True for staged users? Should we even
> manipulate it in stageduser plugin?

No, thinking hard about it I think nsAccountLock should be completely
ignored in the staged area. It is an operational attribute that is
responsibility of IPA admins, provisioning systems have nothing to do
with it. If they do not want a user to be available they simply do not
provision it. If they do then it is on the admin to decide if/when to
unstage the user and make it available.

> The original reason why I proposed it in
> http://www.freeipa.org/page/V4/User_Life-Cycle_Management
> is to prevent LDAP BINDs on such user or Kerberos authentication on such user.
> Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND
> pre-bind callback to prevent authentication to users in 
> cn=provisioning,SUFFIX?

The staged user should have it's userPassword anmd KrbKerberosKey
removed, so no binding should be possible.

> This would allow us to be sure that nobody can bind/authenticate to these 
> users
> without having to manipulate nsAccountLock attribute.

We should just make sure no credentials are set ?
Is there any valid reson for the provisioning system to be allowed to
set userPassword ? (It can't set KrbKerberosKey anyway)

Alternatively/optionally just set a CoS that enforces nsAccountLock to
be set on all staged entries without having to explicitly set it ?

> The only downside is that this would not be effective in older FreeIPA
> versions, but AFAIR, we specified that if User Life Cycle is enabled, all
> server should have at least 4.1 - otherwise for example deleted users would be
> put to the special container or old servers would not have the appropriate DS
> plugins updates.

Yeah I do not see an issue with older servers, esp if we do not allow
credentials on the entry anyway.

Simo.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server

[Simo Sorce]

On Wed, 2014-06-18 at 11:39 +0200, thierry bordaz wrote:
> On 06/17/2014 09:42 PM, Simo Sorce wrote:
> > On Tue, 2014-06-17 at 21:36 +0200, thierry bordaz wrote:
> >> On 06/17/2014 09:29 PM, Simo Sorce wrote:
> >>> On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote:
>  Simo Sorce wrote:
> > On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote:
> >> * ipa stageuser-add  --from-delete
> >>
> >>   It moves a deleted entry to staging container where
> >>
> >>   uidNumber:  >>   prevous active account>
> >>   gidNumber:  >>   prevous active account>
> >>   ipaUniqueID: autogenerate (reset to autogenerate)
> > Why are you resetting the unique id ?
>  Read back a few in the thread. I suggested, perhaps incorrectly, that
>  given that there should be no more references to the user once they go
>  into deleted or staged, it may be ok to reset this value.
> >>> Well, let me reiterate, the deleted bucket is for those environments
> >>> where they have a mandate (regulation, law, policy, etc..) to never
> >>> delete users and reinstate users if they are deleted.
> >>> So all uniquely identifying information should be preserved in case the
> >>> object is revived. This means we need to do our best to preserve all
> >>> these attributes if we can.
> >> This is what is done when an Active user is deleted.
> >> uidNumber/gidNumber/ipaUniqueID are preserved.
> >> When activating a user, currently UUID plugin prevents to set a value.
> >> Should it be relaxed.. I feel not. It is a sensitive info and
> >> provisioning system should not define it.
> > Why is it sensitive ? A ipaUniqueID is not really sensitive, it just
> > needs to be unique.
> 
> Ok.  I believed it was :-)
> 
> I have a concern, if a provisioning system is free to define this value, 
> I wonder if it can create problem for replication.
> For example a provisioning system creates two staging entries on 
> different servers but with the same ipaUniqueID value.

A provisioning system should never have to contact 2 different servers,
what would be the point ?
And then on top of that generate the same UUID ?
Well don't do that, fix your provisioning tool.

> If the entries are activated at the same time, the ADDs operation 
> (activation)  will not be replicated because the attribute uniqueness 
> plugin will reject it.

Right, don't do that.

> This case existed before if two  IPA uuid plugins generated identical 
> value on different replica. But the probability was less than if the 
> provisioning system is free to set it.

Sure, but who cares ? I mean there are *many* ways to whose a system,
the provisioning system can simply create 2 users accounts with the same
name on 2 servers and get them activated at the same time and you get
the same issue as uid is also unique. Just fix the malfunctioning
provisioning system.

> >> When undelete a user (move Delete->Staging), ipaUniqueID can be
> >> preserved but as the purpose of Staging entry is to become active I
> >> thought it would be better to wipe the value also at this time.
> > I understand that (and I noted before that I think deleted->staged is a
> > bad idea IMO :-) ), but you are wiping it only as a workaround, because
> > the plugin prevents you from adding it. Would have you wiped it if it
> > were not the case ? And if so, why ?
> 
> That is correct. I thought to wipe it because the plugin rejected values 
> others than 'autogenerate'.
> 
> To relax the control that rejects values other than 'autogenerate', I 
> need to modify the plugin. Should it be done under an other ticket or 
> can it be part of this RFE ?

I think it can be part of this RFE, should we use the Relax Control for
this ? I think it may still valuable to enforce the rule in non-staging
cases.

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] User life-cycle: nsAccountLock

[Simo Sorce]

On Wed, 2014-06-18 at 15:22 +0200, thierry bordaz wrote:
> On 06/18/2014 12:47 PM, Martin Kosek wrote:
> > On 06/17/2014 05:59 PM, thierry bordaz wrote:
> >> On 06/16/2014 03:04 PM, Rob Crittenden wrote:
> > ...
> >> Thanks for your precise feedback and sorry for my late answer.
> >> So if I try to consolidate my understandings, the workflow would be:
> >>
> >>  1. Staging (container: cn=staged
> >> users,cn=accounts,cn=provisioning,SUFFIX)
> >>   * ipa stageuser-add 
> >> It creates a stage entry with
> >>
> >> uidNumber: -1
> >> gidNumber: -1
> >> ipaUniqueID: autogenerate
> >> description: __no_upg__
> >> manager: checks that the DN is an active user
> >> nsAccountLock: True
> > I was thinking about the nsAccountLock part again. Should we really force
> > provisioning systems to set it to True for staged users? Should we even
> > manipulate it in stageduser plugin?
> 
> That is correct, provisioning system can create entries in Staging area 
> without nsAccountLock or with nsAccountLock: False.
> With stageuser-add we have this ability but as you described below it 
> can be done with different ways.
> 
> We may create a new DS plugin to enforce added stage entries (or 
> modifications) have the expected values. But I think the idea was to 
> make Stage container free to receive any kind of entries. This was the 
> activation job to make the control.
> 
> activation (stageuser-activate) is setting 'nsAccountLock: False' so 
> currently at least this method is manipulating nsAccountLock.

Shouldn't it just remove the attribute if present ?

> > The original reason why I proposed it in
> > http://www.freeipa.org/page/V4/User_Life-Cycle_Management
> > is to prevent LDAP BINDs on such user or Kerberos authentication on such 
> > user.
> > Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND
> > pre-bind callback to prevent authentication to users in 
> > cn=provisioning,SUFFIX?
> Sure this solution would also have the advantages to prevent 
> authentication from Staging/Delete container and allow authentication 
> only from 'Active' container.
> For LDAP BIND pre-bind which plugin are you thinking of ? a new one ?
> 
> About Kerberos update, my understanding is that if we restrict (in sasl 
> mapping) the baseDN template (nsSaslMapBaseDNTemplate) to 
> cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication 
> only to Active user. Is that correct ?

No, we have many other principals that can bind to DS in
cn=computers,cn=users cn=services,cn=users and cn=kerberos at least, you
cannot exclude those. Besides there are also simple binds.

Simo.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User life-cycle: nsAccountLock

[thierry bordaz]

On 06/18/2014 03:40 PM, Simo Sorce wrote:

On Wed, 2014-06-18 at 15:22 +0200, thierry bordaz wrote:

On 06/18/2014 12:47 PM, Martin Kosek wrote:

On 06/17/2014 05:59 PM, thierry bordaz wrote:

On 06/16/2014 03:04 PM, Rob Crittenden wrote:

...

 Thanks for your precise feedback and sorry for my late answer.
 So if I try to consolidate my understandings, the workflow would be:

  1. Staging (container: cn=staged
 users,cn=accounts,cn=provisioning,SUFFIX)
   * ipa stageuser-add 
 It creates a stage entry with

 uidNumber: -1
 gidNumber: -1
 ipaUniqueID: autogenerate
 description: __no_upg__
 manager: checks that the DN is an active user
 nsAccountLock: True

I was thinking about the nsAccountLock part again. Should we really force
provisioning systems to set it to True for staged users? Should we even
manipulate it in stageduser plugin?

That is correct, provisioning system can create entries in Staging area
without nsAccountLock or with nsAccountLock: False.
With stageuser-add we have this ability but as you described below it
can be done with different ways.

We may create a new DS plugin to enforce added stage entries (or
modifications) have the expected values. But I think the idea was to
make Stage container free to receive any kind of entries. This was the
activation job to make the control.

activation (stageuser-activate) is setting 'nsAccountLock: False' so
currently at least this method is manipulating nsAccountLock.

Shouldn't it just remove the attribute if present ?


Yes as we decide to not use this attribute to allow/disallow . I will 
remove it from CLIs



The original reason why I proposed it in
http://www.freeipa.org/page/V4/User_Life-Cycle_Management
is to prevent LDAP BINDs on such user or Kerberos authentication on such user.
Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND
pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX?

Sure this solution would also have the advantages to prevent
authentication from Staging/Delete container and allow authentication
only from 'Active' container.
For LDAP BIND pre-bind which plugin are you thinking of ? a new one ?

About Kerberos update, my understanding is that if we restrict (in sasl
mapping) the baseDN template (nsSaslMapBaseDNTemplate) to
cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication
only to Active user. Is that correct ?

No, we have many other principals that can bind to DS in
cn=computers,cn=users cn=services,cn=users and cn=kerberos at least, you
cannot exclude those. Besides there are also simple binds.

Ok.
We want to exclude 'Stage' and 'Delete' containers. A possibility is to 
create a new multivalued attribute (like 'nsSaslMapExcludeSubtree') for 
nsSaslMapping entry.


thanks
thierry


Simo.




___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 302 Do not corrupt sshd_config in client install when trailing newline is missing

[Jan Cholasta]

Hi,

the attached patch fixes .

Honza

--
Jan Cholasta
>From c933fa17a556ccc7ce142f81c6d6aaac15d0931d Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Wed, 18 Jun 2014 15:26:17 +0200
Subject: [PATCH] Do not corrupt sshd_config in client install when trailing
 newline is missing.

https://fedorahosted.org/freeipa/ticket/4373
---
 ipa-client/ipa-install/ipa-client-install | 42 +--
 1 file changed, 17 insertions(+), 25 deletions(-)

diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index c20ad1a..307b593 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -1259,7 +1259,7 @@ def configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, options, clie
 return 0
 
 def change_ssh_config(filename, changes, sections):
-if len(changes) == 0:
+if not changes:
 return True
 
 try:
@@ -1268,38 +1268,30 @@ def change_ssh_config(filename, changes, sections):
 root_logger.error("Failed to open '%s': %s", filename, str(e))
 return False
 
+change_keys = tuple(key.lower() for key in changes)
+section_keys = tuple(key.lower() for key in sections)
+
 lines = []
-in_section = False
 for line in f:
-if in_section:
-lines.append(line)
-continue
+line = line.rstrip('\n')
 pline = line.strip()
-if len(pline) == 0 or pline.startswith('#'):
+if not pline or pline.startswith('#'):
 lines.append(line)
 continue
-parts = pline.split()
-option = parts[0].lower()
-for key in sections:
-if key.lower() == option:
-in_section = True
-break
-if in_section:
-break
-for opt in changes:
-if opt.lower() == option:
-line = None
-break
-if line is not None:
+option = pline.split()[0].lower()
+if option in section_keys:
 lines.append(line)
-for opt in changes:
-if changes[opt] is not None:
-lines.append('%s %s\n' % (opt, changes[opt]))
-lines.append('\n')
-if in_section:
+break
+if option in change_keys:
+line = '#' + line
 lines.append(line)
+for option, value in changes.items():
+if value is not None:
+lines.append('%s %s' % (option, value))
 for line in f:
+line = line.rstrip('\n')
 lines.append(line)
+lines.append('')
 
 f.close()
 
@@ -1309,7 +1301,7 @@ def change_ssh_config(filename, changes, sections):
 root_logger.error("Failed to open '%s': %s", filename, str(e))
 return False
 
-f.write(''.join(lines))
+f.write('\n'.join(lines))
 
 f.close()
 
-- 
1.9.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User life-cycle: nsAccountLock

[thierry bordaz]

On 06/18/2014 03:31 PM, Simo Sorce wrote:

On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote:

On 06/17/2014 05:59 PM, thierry bordaz wrote:

On 06/16/2014 03:04 PM, Rob Crittenden wrote:

...

Thanks for your precise feedback and sorry for my late answer.
So if I try to consolidate my understandings, the workflow would be:

 1. Staging (container: cn=staged
users,cn=accounts,cn=provisioning,SUFFIX)
  * ipa stageuser-add 
It creates a stage entry with

uidNumber: -1
gidNumber: -1
ipaUniqueID: autogenerate
description: __no_upg__
manager: checks that the DN is an active user
nsAccountLock: True

I was thinking about the nsAccountLock part again. Should we really force
provisioning systems to set it to True for staged users? Should we even
manipulate it in stageduser plugin?

No, thinking hard about it I think nsAccountLock should be completely
ignored in the staged area. It is an operational attribute that is
responsibility of IPA admins, provisioning systems have nothing to do
with it. If they do not want a user to be available they simply do not
provision it. If they do then it is on the admin to decide if/when to
unstage the user and make it available.


A Stage user is waiting for an approval before being Active. And an 
approver may have a look at its properties to decide.
During the time it remains in Staging, admin do not want someone to bind 
with that entry even if the provisioning system set the password.

pre-bind plugin or cos are possibilites to prevent binding with that entry.




The original reason why I proposed it in
http://www.freeipa.org/page/V4/User_Life-Cycle_Management
is to prevent LDAP BINDs on such user or Kerberos authentication on such user.
Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND
pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX?

The staged user should have it's userPassword anmd KrbKerberosKey
removed, so no binding should be possible.


That means a Delete user being staged (ipa stageuser-add  
--from-delete) will loose its password/keys.
I believe it is an acceptable limitation else the admin would prefere to 
do 'ipa user-undelete '.



This would allow us to be sure that nobody can bind/authenticate to these users
without having to manipulate nsAccountLock attribute.

We should just make sure no credentials are set ?
Is there any valid reson for the provisioning system to be allowed to
set userPassword ? (It can't set KrbKerberosKey anyway)
Does that mean stageuser-add/mod should not support options around 
password setting ?


Alternatively/optionally just set a CoS that enforces nsAccountLock to
be set on all staged entries without having to explicitly set it ?


The only downside is that this would not be effective in older FreeIPA
versions, but AFAIR, we specified that if User Life Cycle is enabled, all
server should have at least 4.1 - otherwise for example deleted users would be
put to the special container or old servers would not have the appropriate DS
plugins updates.

Yeah I do not see an issue with older servers, esp if we do not allow
credentials on the entry anyway.

Simo.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User life-cycle: nsAccountLock

[Simo Sorce]

On Wed, 2014-06-18 at 15:55 +0200, thierry bordaz wrote:
> On 06/18/2014 03:40 PM, Simo Sorce wrote:
> > On Wed, 2014-06-18 at 15:22 +0200, thierry bordaz wrote:
> >> On 06/18/2014 12:47 PM, Martin Kosek wrote:
> >>> On 06/17/2014 05:59 PM, thierry bordaz wrote:
>  On 06/16/2014 03:04 PM, Rob Crittenden wrote:
> >>> ...
>   Thanks for your precise feedback and sorry for my late answer.
>   So if I try to consolidate my understandings, the workflow would be:
> 
>    1. Staging (container: cn=staged
>   users,cn=accounts,cn=provisioning,SUFFIX)
> * ipa stageuser-add 
>   It creates a stage entry with
> 
>   uidNumber: -1
>   gidNumber: -1
>   ipaUniqueID: autogenerate
>   description: __no_upg__
>   manager: checks that the DN is an active user
>   nsAccountLock: True
> >>> I was thinking about the nsAccountLock part again. Should we really force
> >>> provisioning systems to set it to True for staged users? Should we even
> >>> manipulate it in stageduser plugin?
> >> That is correct, provisioning system can create entries in Staging area
> >> without nsAccountLock or with nsAccountLock: False.
> >> With stageuser-add we have this ability but as you described below it
> >> can be done with different ways.
> >>
> >> We may create a new DS plugin to enforce added stage entries (or
> >> modifications) have the expected values. But I think the idea was to
> >> make Stage container free to receive any kind of entries. This was the
> >> activation job to make the control.
> >>
> >> activation (stageuser-activate) is setting 'nsAccountLock: False' so
> >> currently at least this method is manipulating nsAccountLock.
> > Shouldn't it just remove the attribute if present ?
> 
> Yes as we decide to not use this attribute to allow/disallow . I will 
> remove it from CLIs
> >
> >>> The original reason why I proposed it in
> >>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management
> >>> is to prevent LDAP BINDs on such user or Kerberos authentication on such 
> >>> user.
> >>> Wouldn't it be better to simply just update KDC backend plugin and LDAP 
> >>> BIND
> >>> pre-bind callback to prevent authentication to users in 
> >>> cn=provisioning,SUFFIX?
> >> Sure this solution would also have the advantages to prevent
> >> authentication from Staging/Delete container and allow authentication
> >> only from 'Active' container.
> >> For LDAP BIND pre-bind which plugin are you thinking of ? a new one ?
> >>
> >> About Kerberos update, my understanding is that if we restrict (in sasl
> >> mapping) the baseDN template (nsSaslMapBaseDNTemplate) to
> >> cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication
> >> only to Active user. Is that correct ?
> > No, we have many other principals that can bind to DS in
> > cn=computers,cn=users cn=services,cn=users and cn=kerberos at least, you
> > cannot exclude those. Besides there are also simple binds.
> Ok.
> We want to exclude 'Stage' and 'Delete' containers. A possibility is to 
> create a new multivalued attribute (like 'nsSaslMapExcludeSubtree') for 
> nsSaslMapping entry.

I fail to see the need for this.
In order to be able to to GSSAPI authentication you need to be able to
acquire a ticket for the principal, but the KrbKerberosKey should be
removed when deleting a user and the provisioning system has no way to
create it in the staged entries. So there should be no way for a
principal to make an AS request to start with nor a TGS request, so it
should never be able to have a ticket that would map to one of those
entries.

Also just changing the Sasl mapping will not preclude simple binds ?
But can we simply delete userPassword from deleted and prevent it to be
set in staging (or alternatively force accountlock) ?
Third alternative is to change the ipa pre-bind plugin to preclude any
binding for entries in deleted/staged

Simo.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User life-cycle: nsAccountLock

[Simo Sorce]

On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote:
> On 06/18/2014 03:31 PM, Simo Sorce wrote:
> > On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote:
> >> On 06/17/2014 05:59 PM, thierry bordaz wrote:
> >>> On 06/16/2014 03:04 PM, Rob Crittenden wrote:
> >> ...
> >>> Thanks for your precise feedback and sorry for my late answer.
> >>> So if I try to consolidate my understandings, the workflow would be:
> >>>
> >>>  1. Staging (container: cn=staged
> >>> users,cn=accounts,cn=provisioning,SUFFIX)
> >>>   * ipa stageuser-add 
> >>> It creates a stage entry with
> >>>
> >>> uidNumber: -1
> >>> gidNumber: -1
> >>> ipaUniqueID: autogenerate
> >>> description: __no_upg__
> >>> manager: checks that the DN is an active user
> >>> nsAccountLock: True
> >> I was thinking about the nsAccountLock part again. Should we really force
> >> provisioning systems to set it to True for staged users? Should we even
> >> manipulate it in stageduser plugin?
> > No, thinking hard about it I think nsAccountLock should be completely
> > ignored in the staged area. It is an operational attribute that is
> > responsibility of IPA admins, provisioning systems have nothing to do
> > with it. If they do not want a user to be available they simply do not
> > provision it. If they do then it is on the admin to decide if/when to
> > unstage the user and make it available.
> 
> A Stage user is waiting for an approval before being Active. And an 
> approver may have a look at its properties to decide.
> During the time it remains in Staging, admin do not want someone to bind 
> with that entry even if the provisioning system set the password.
> pre-bind plugin or cos are possibilites to prevent binding with that entry.

Right, if we allow setting userPassword this would happen, but then if
we allow setting userPassword do we also generate Kerberos Keys ?

If this is the case then we probably need to change the pre-bind plugin
(and ipa-kdb ?) to explicitly exclude staging (and deleted ?).

I was actually planning to use staging to allow kadmin to create
entries, so we need to be careful how ipa-kdb limits access to staging,
I would guess it should pretend KrbKerberosKey is not present for those
entries.

> >> The original reason why I proposed it in
> >> http://www.freeipa.org/page/V4/User_Life-Cycle_Management
> >> is to prevent LDAP BINDs on such user or Kerberos authentication on such 
> >> user.
> >> Wouldn't it be better to simply just update KDC backend plugin and LDAP 
> >> BIND
> >> pre-bind callback to prevent authentication to users in 
> >> cn=provisioning,SUFFIX?
> > The staged user should have it's userPassword anmd KrbKerberosKey
> > removed, so no binding should be possible.
> 
> That means a Delete user being staged (ipa stageuser-add  
> --from-delete) will loose its password/keys.
> I believe it is an acceptable limitation else the admin would prefere to 
> do 'ipa user-undelete '.

What I meant here is the ipa-del would drop the passwords and keys, so
there is no undelete that will restore them. But if we think we should
preserve them then the above option (change in ipa-kdb plugin) is the
best way to go to mask out these entries.

> >> This would allow us to be sure that nobody can bind/authenticate to these 
> >> users
> >> without having to manipulate nsAccountLock attribute.
> > We should just make sure no credentials are set ?
> > Is there any valid reson for the provisioning system to be allowed to
> > set userPassword ? (It can't set KrbKerberosKey anyway)
> Does that mean stageuser-add/mod should not support options around 
> password setting ?

Well the problem is that is you allow setting userPassword then you need
it in the clear and have to also generate Kerberos Keys, and then we
need to prevent them from being used (ipa-kdb change).

Allowing to set a pre-hashed userPassword won't work because then the
user cannot authenticate with Kerberos and the server need to be
permanently set in migration mode or the user must be forced to go
somewhere to change the password so setting a pre-shared password in the
first place is basically useless.

Otherwise we can simply forbid them being set by provisioning and the
only thing we need to do is to remove userPassword/KrbPrincipalKey when
the user is moved to the deleted tree.

Simo.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains

[Martin Basti]

Due to compability with older versions, only IDNA domains should be
checked
Patch attached.
-- 
Martin^2 Basti
>From fd329148639ce5b5707f37d1b450597f3ca4bcb7 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Wed, 18 Jun 2014 15:58:17 +0200
Subject: [PATCH] Check normalization only for IDNA domains

Backward compability with older IPA versions which allow to use uppper
case. Only IDNA domains will be checked.
---
 ipalib/parameters.py| 24 ++--
 ipatests/test_xmlrpc/test_dns_plugin.py |  4 ++--
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/ipalib/parameters.py b/ipalib/parameters.py
index 1dff13cc1371c26208cacd8a7cbaf44634622e4a..ffd20fddae4257c51297f0221231aa2cadad9d58 100644
--- a/ipalib/parameters.py
+++ b/ipalib/parameters.py
@@ -1961,16 +1961,20 @@ class DNSNameParam(Param):
 error = _('DNS label cannot be longer than 63 characters')
 except dns.exception.SyntaxError:
 error = _('invalid domain name')
-
-#compare if IDN normalized and original domain match
-#there is N:1 mapping between unicode and IDNA names
-#user should use normalized names to avoid mistakes
-normalized_domain_name = encodings.idna.nameprep(value)
-if value != normalized_domain_name:
-error = _("domain name '%(domain)s' and normalized domain name"
-  " '%(normalized)s' do not match. Please use only"
-  " normalized domains") % {'domain': value,
-  'normalized': normalized_domain_name}
+else:
+if domain_name.is_idn() or u'\xdf' in value:
+#compare if IDN normalized and original domain match
+#there is N:1 mapping between unicode and IDNA names
+#user should use normalized names to avoid mistakes
+# u'\xdf' is special case, german 'eszett' character, which
+# is mapped to 'ss'
+normalized_domain_name = encodings.idna.nameprep(value)
+if value != normalized_domain_name:
+error = _("domain name '%(domain)s' and normalized "
+  "domain name '%(normalized)s' do not match. "
+  "Please use only normalized IDNA domains") % {
+'domain': value,
+'normalized': normalized_domain_name}
 if error:
 raise ConversionError(name=self.get_param_name(), index=index,
   error=error)
diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py b/ipatests/test_xmlrpc/test_dns_plugin.py
index dd105990f0da2c7aa88c64d7fdc6b9be7b7f8885..9a09e33ff6296da7c60ea91525ddb2209c56ca2e 100644
--- a/ipatests/test_xmlrpc/test_dns_plugin.py
+++ b/ipatests/test_xmlrpc/test_dns_plugin.py
@@ -2432,11 +2432,11 @@ class test_dns(Declarative):
 
 
 dict(
-desc='Add A denormalized record to %r in zone %r' % (idnres1, idnzone1),
+desc='Add A denormalized record in zone %r' % (idnzone1),
 command=('dnsrecord_add', [idnzone1, u'gro\xdf'], {'arecord': u'172.16.0.1'}),
 expected=errors.ConversionError(name='name',
 error=u'domain name \'gro\xdf\' and normalized domain name \'gross\''
-+ ' do not match. Please use only normalized domains'),
++ ' do not match. Please use only normalized IDNA domains'),
 ),
 
 
-- 
1.8.3.1

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH 0229] dsinstance: Detect dynamic plugin support and restart server

[Tomas Babej]

Hi,

With 389-ds-base 1.3.3. comes the dynamic plugin support. We need to
restart the server right after modifying the schema, as the plugins
will be enabled at the point they are added (and not at the next
server restart).

Properly handle both situations in the installer.

https://fedorahosted.org/freeipa/ticket/4203

-- 
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 


>From 8149018cfb81a3e9ec9cb164617f1875656d9354 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Tue, 17 Jun 2014 15:18:49 +0200
Subject: [PATCH] dsinstance: Detect dynamic plugin support and restart server
 accordingly

With 389-ds-base 1.3.3. come the dynamic plugin support. We need to
restart the server right after modifying the schema, as the plugins
will be enabled at the point they are added (and not at the next
server restart).

Properly handle both situations in the installer.

https://fedorahosted.org/freeipa/ticket/4203
---
 ipaserver/install/dsinstance.py | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index 2a9f3b618cc8e165821fefb9cede602cad8d6999..6d208047243019292877624932d5b988be980541 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -262,6 +262,7 @@ class DsInstance(service.Service):
 self.step("creating directory server user", create_ds_user)
 self.step("creating directory server instance", self.__create_instance)
 self.step("adding default schema", self.__add_default_schemas)
+self.step("detecting dynamic plugin support", self.__detect_dynamic_plugin_support)
 self.step("enabling memberof plugin", self.__add_memberof_module)
 self.step("enabling winsync plugin", self.__add_winsync_module)
 self.step("configuring replication version plugin", self.__config_version_module)
@@ -283,7 +284,7 @@ class DsInstance(service.Service):
 self.step("configure new location for managed entries", self.__repoint_managed_entries)
 self.step("configure dirsrv ccache", self.configure_dirsrv_ccache)
 self.step("enable SASL mapping fallback", self.__enable_sasl_mapping_fallback)
-self.step("restarting directory server", self.__restart_instance)
+self.step("restarting directory server", self.__restart_instance_final)
 
 def __common_post_setup(self):
 self.step("initializing group membership", self.init_memberof)
@@ -387,6 +388,23 @@ class DsInstance(service.Service):
 
 self.start_creation(runtime=60)
 
+def __detect_dynamic_plugin_support(self):
+if not self.admin_conn:
+self.ldap_connect()
+
+# Check that dynamic plugins are enabled
+result = self.admin_conn.conn.search_s(
+  DN("cn=config"),
+  ldap.SCOPE_BASE,
+  attrlist=["nsslapd-dynamic-plugins"])[0]
+
+enabled = result.get("nsslapd-dynamic-plugins") == ['on']
+self.dynamic_plugins_enabled = enabled
+
+# If the dynamic plugins are enabled, we need to restart to apply the
+# new schema
+if enabled:
+self.__restart_instance()
 
 def __setup_replica(self):
 replication.enable_replication_version_checking(self.fqdn,
@@ -503,13 +521,20 @@ class DsInstance(service.Service):
 try:
 super(DsInstance, self).restart(instance)
 if not is_ds_running(instance):
-root_logger.critical("Failed to restart the directory server. See the installation log for details.")
+root_logger.critical("Failed to restart the directory server. "
+ "See the installation log for details.")
 sys.exit(1)
 except SystemExit, e:
 raise e
 except Exception, e:
 # TODO: roll back here?
-root_logger.critical("Failed to restart the directory server (%s). See the installation log for details." % e)
+root_logger.critical("Failed to restart the directory server (%s). "
+ "See the installation log for details." % e)
+
+def __restart_instance_final(self):
+# This restart is necessary only if dynamic plugins are not allowed
+if not self.dynamic_plugins_enabled:
+self.__restart_instance()
 
 def __restart_instance(self):
 self.restart(self.serverid)
-- 
1.9.3

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH 0019] Clarify LDAPClient docstrings about get_entry, get_entries and find_entrie

[Petr Spacek]

Hello,

Clarify LDAPClient docstrings about get_entry, get_entries and find_entries.


BTW what is the purpose of size_limit in LDAPClient.get_entry()?

def get_entry(self, dn, attrs_list=None, time_limit=None,
  size_limit=None)

--
Petr^2 Spacek
From 0b6e1940f05b02c1aae0f390239b79396e8b1391 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Wed, 18 Jun 2014 17:31:53 +0200
Subject: [PATCH] Clarify LDAPClient docstrings about get_entry, get_entries
 and find_entries

---
 ipapython/ipaldap.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/ipapython/ipaldap.py b/ipapython/ipaldap.py
index 677e4f8071b2303c9beeb0a58972684814ecc382..21706cff08a0d8be07db8a1b5fdb0367c10ad53d 100644
--- a/ipapython/ipaldap.py
+++ b/ipapython/ipaldap.py
@@ -1392,7 +1392,9 @@ class LDAPClient(object):
 attrs_list=None):
 """Return a list of matching entries.
 
-Raises an error if the list is truncated by the server
+:raises: errors.LimitsExceeded if the list is truncated by the server
+:raises: errors.NotFound if result set is empty
+ or base_dn doesn't exist
 
 :param base_dn: dn of the entry at which to start the search
 :param scope: search scope, see LDAP docs (default ldap2.SCOPE_SUBTREE)
@@ -1426,6 +1428,9 @@ class LDAPClient(object):
 search_refs -- allow search references to be returned
 (default skips these entries)
 paged_search -- search using paged results control
+
+:raises: errors.NotFound if result set is empty
+ or base_dn doesn't exist
 """
 if base_dn is None:
 base_dn = DN()
-- 
1.9.3

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 0578-0579 Convert Host default permissions to managed

[Martin Kosek]

On 06/11/2014 06:39 PM, Petr Viktorin wrote:
> Patch 0578 does the conversion
> 
> Patch 0579 fixes https://fedorahosted.org/freeipa/ticket/4252 and provides
> permissions needed for automatic enrollment (from
> http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser)

1) Inconsistent casing in permission names:

System: Add Hosts
System: Add krbPrincipalName to a host
System: Enroll a host
System: Manage Host SSH Public Keys
System: Manage host keytab
System: Modify Hosts
System: Remove Hosts


2) This ACI does not look right, missing enrolledby:

+'System: Enroll a host': {
+'ipapermright': {'write'},
+'ipapermdefaultattr': {'objectclass'},

When I fixed 2) via permission-mod, client enrollment with user with "Host
Administrators" privilege worked fine.


3) I hit one issue when I open the Web UI host tab, I get "Insufficient access:
No such virtual command" error triggered by "cert-show" command.

We will need to add the permission "System: Read Virtual Operations" that Honza
is creating also to "Host Administrators" to fix that part.


4) I ran unit tests and few missing attributes:
- update hosts ACI should get "macaddress" attribute


5) I hit one nasty issue when running the unit tests (when my master stopped
working as host account was deleted) - host_is_master function in baseldap no
longer works as we hid cn=masters from regular users:

def host_is_master(ldap, fqdn):
"""
Check to see if this host is a master.

Raises an exception if a master, otherwise returns nothing.
"""
master_dn = DN(('cn', fqdn), ('cn', 'masters'), ('cn', 'ipa'), ('cn',
'etc'), api. env.basedn)
try:
ldap.get_entry(master_dn, ['objectclass'])
raise errors.ValidationError(name='hostname', error=_('An IPA master
host  cannot be deleted or disabled'))
except errors.NotFound:
# Good, not a master
return

This means, that host-del on a master machine or service-del on master service
happily passes.

We need to make sure this functionality is still working after the permission
refactoring. Should we reconsider the cn=masters tree and allow authenticated
users see the list of IPA servers (without digging into any other detail like
services) then?

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User life-cycle: nsAccountLock

[thierry bordaz]

On 06/18/2014 04:45 PM, Simo Sorce wrote:

On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote:

On 06/18/2014 03:31 PM, Simo Sorce wrote:

On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote:

On 06/17/2014 05:59 PM, thierry bordaz wrote:

On 06/16/2014 03:04 PM, Rob Crittenden wrote:

...

 Thanks for your precise feedback and sorry for my late answer.
 So if I try to consolidate my understandings, the workflow would be:

  1. Staging (container: cn=staged
 users,cn=accounts,cn=provisioning,SUFFIX)
   * ipa stageuser-add 
 It creates a stage entry with

 uidNumber: -1
 gidNumber: -1
 ipaUniqueID: autogenerate
 description: __no_upg__
 manager: checks that the DN is an active user
 nsAccountLock: True

I was thinking about the nsAccountLock part again. Should we really force
provisioning systems to set it to True for staged users? Should we even
manipulate it in stageduser plugin?

No, thinking hard about it I think nsAccountLock should be completely
ignored in the staged area. It is an operational attribute that is
responsibility of IPA admins, provisioning systems have nothing to do
with it. If they do not want a user to be available they simply do not
provision it. If they do then it is on the admin to decide if/when to
unstage the user and make it available.

A Stage user is waiting for an approval before being Active. And an
approver may have a look at its properties to decide.
During the time it remains in Staging, admin do not want someone to bind
with that entry even if the provisioning system set the password.
pre-bind plugin or cos are possibilites to prevent binding with that entry.

Right, if we allow setting userPassword this would happen, but then if
we allow setting userPassword do we also generate Kerberos Keys ?
Currently setting of the userPassword (add entry or mod entry) triggers 
generation of krb keys (I guess in ipa-kdb).


If this is the case then we probably need to change the pre-bind plugin
(and ipa-kdb ?) to explicitly exclude staging (and deleted ?).
Do you mean to prevent ipa-kdb to generate krb keys when the this is 
Delete/Staging


I was actually planning to use staging to allow kadmin to create
entries, so we need to be careful how ipa-kdb limits access to staging,
I would guess it should pretend KrbKerberosKey is not present for those
entries.


The original reason why I proposed it in
http://www.freeipa.org/page/V4/User_Life-Cycle_Management
is to prevent LDAP BINDs on such user or Kerberos authentication on such user.
Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND
pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX?

The staged user should have it's userPassword anmd KrbKerberosKey
removed, so no binding should be possible.

That means a Delete user being staged (ipa stageuser-add 
--from-delete) will loose its password/keys.
I believe it is an acceptable limitation else the admin would prefere to
do 'ipa user-undelete '.

What I meant here is the ipa-del would drop the passwords and keys, so
there is no undelete that will restore them. But if we think we should
preserve them then the above option (change in ipa-kdb plugin) is the
best way to go to mask out these entries.

I do not know what are the consequences of dropping password and keys.
A use case would be someone that returns back to an organization and get 
his account undelete. This person will likely remember his previous 
password and would expect to be authenticate with kerberos using that 
password.
Now if password and keys have been removed, he should reset his password 
before being authenticate. I think it is an acceptable limitation.





This would allow us to be sure that nobody can bind/authenticate to these users
without having to manipulate nsAccountLock attribute.

We should just make sure no credentials are set ?
Is there any valid reson for the provisioning system to be allowed to
set userPassword ? (It can't set KrbKerberosKey anyway)

Does that mean stageuser-add/mod should not support options around
password setting ?

Well the problem is that is you allow setting userPassword then you need
it in the clear and have to also generate Kerberos Keys, and then we
need to prevent them from being used (ipa-kdb change).

Allowing to set a pre-hashed userPassword won't work because then the
user cannot authenticate with Kerberos and the server need to be
permanently set in migration mode or the user must be forced to go
somewhere to change the password so setting a pre-shared password in the
first place is basically useless.

Otherwise we can simply forbid them being set by provisioning and the
only thing we need to do is to remove userPassword/KrbPrincipalKey when
the user is moved to the deleted tree.

Simo.





___
Freeipa-devel mailing list
Freeipa-devel@r

Re: [Freeipa-devel] User life-cycle: nsAccountLock

[Simo Sorce]

On Wed, 2014-06-18 at 17:49 +0200, thierry bordaz wrote:
> On 06/18/2014 04:45 PM, Simo Sorce wrote:
> > On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote:
> >> On 06/18/2014 03:31 PM, Simo Sorce wrote:
> >>> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote:
>  On 06/17/2014 05:59 PM, thierry bordaz wrote:
> > On 06/16/2014 03:04 PM, Rob Crittenden wrote:
>  ...
> >  Thanks for your precise feedback and sorry for my late answer.
> >  So if I try to consolidate my understandings, the workflow would 
> > be:
> >
> >   1. Staging (container: cn=staged
> >  users,cn=accounts,cn=provisioning,SUFFIX)
> >* ipa stageuser-add 
> >  It creates a stage entry with
> >
> >  uidNumber: -1
> >  gidNumber: -1
> >  ipaUniqueID: autogenerate
> >  description: __no_upg__
> >  manager: checks that the DN is an active user
> >  nsAccountLock: True
>  I was thinking about the nsAccountLock part again. Should we really force
>  provisioning systems to set it to True for staged users? Should we even
>  manipulate it in stageduser plugin?
> >>> No, thinking hard about it I think nsAccountLock should be completely
> >>> ignored in the staged area. It is an operational attribute that is
> >>> responsibility of IPA admins, provisioning systems have nothing to do
> >>> with it. If they do not want a user to be available they simply do not
> >>> provision it. If they do then it is on the admin to decide if/when to
> >>> unstage the user and make it available.
> >> A Stage user is waiting for an approval before being Active. And an
> >> approver may have a look at its properties to decide.
> >> During the time it remains in Staging, admin do not want someone to bind
> >> with that entry even if the provisioning system set the password.
> >> pre-bind plugin or cos are possibilites to prevent binding with that entry.
> > Right, if we allow setting userPassword this would happen, but then if
> > we allow setting userPassword do we also generate Kerberos Keys ?

> Currently setting of the userPassword (add entry or mod entry) triggers 
> generation of krb keys (I guess in ipa-kdb).

No it happen in ipa-pwd-extop

> > If this is the case then we probably need to change the pre-bind plugin
> > (and ipa-kdb ?) to explicitly exclude staging (and deleted ?).

> Do you mean to prevent ipa-kdb to generate krb keys when the this is 
> Delete/Staging

No I mean to prevent the ipa-kdb driver (it's the KDC driver) from
returning any key even if present for entries in those suffixes.

> > I was actually planning to use staging to allow kadmin to create
> > entries, so we need to be careful how ipa-kdb limits access to staging,
> > I would guess it should pretend KrbKerberosKey is not present for those
> > entries.
> >
>  The original reason why I proposed it in
>  http://www.freeipa.org/page/V4/User_Life-Cycle_Management
>  is to prevent LDAP BINDs on such user or Kerberos authentication on such 
>  user.
>  Wouldn't it be better to simply just update KDC backend plugin and LDAP 
>  BIND
>  pre-bind callback to prevent authentication to users in 
>  cn=provisioning,SUFFIX?
> >>> The staged user should have it's userPassword anmd KrbKerberosKey
> >>> removed, so no binding should be possible.
> >> That means a Delete user being staged (ipa stageuser-add 
> >> --from-delete) will loose its password/keys.
> >> I believe it is an acceptable limitation else the admin would prefere to
> >> do 'ipa user-undelete '.
> > What I meant here is the ipa-del would drop the passwords and keys, so
> > there is no undelete that will restore them. But if we think we should
> > preserve them then the above option (change in ipa-kdb plugin) is the
> > best way to go to mask out these entries.

> I do not know what are the consequences of dropping password and keys.

It means the entry cannot be used as an authentication source :)

> A use case would be someone that returns back to an organization and get 
> his account undelete. This person will likely remember his previous 
> password and would expect to be authenticate with kerberos using that 
> password.

TBH I think the likelihood of remembering an unused years old password
is very low, and they would probably be expired anyway ...

> Now if password and keys have been removed, he should reset his password 
> before being authenticate. I think it is an acceptable limitation.

I think it may be a desirable feature rather than a limitation :-)

Simo.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DNSSEC key metadata handling

[Petr Spacek]

On 13.6.2014 18:43, Petr Spacek wrote:

On 12.6.2014 17:49, Petr Spacek wrote:

On 12.6.2014 17:19, Simo Sorce wrote:

On Thu, 2014-06-12 at 17:08 +0200, Petr Spacek wrote:

Hello list,

I have realized that we need to store certain DNSSEC metadata for every
(zone,key,replica) triplet. It is necessary to handle splits in replication
topology.

DNSSEC key can be in one of following states:
- key created
- published but not used for signing
- published and used for signing
- published and not used for signing but old signatures exist
- unpublished

Every state transition has to be postponed until relevant TTL expires, and of
course, we need to consider TTL on all replicas.


Example of a problem

DNS TTL=10 units
Key life time=100 units

Replica=1 Key=1 Time=0   Published
Replica=2 Key=1 Time=0   Published
Replica=1 Key=1 Time=10  Published, signing
Replica=2 Key=1 Time=10  Published, signing
Replica=1 Key=2 Time=90  Generated, published, not signing yet
Replica=2 Key=2 Time=90  
Replica=1 Key=1 Time=100
^^^ From time=100, all new signatures should be created with key=2 but that
can break DNSSEC validation because key=2 is not available on replica=2.


Can you explain how this break validation ?
Aren't signatures regenerated on each replica ?

They are.


And so isn't each replica self-consistent ?

Ah, sorry, I didn't mention one important detail. Keys published in the zone
'example.com.' have to match keys published in parent zone. There has to be a
mechanism for synchronizing this.

Validation will break if (keys published by parent) are not subset of (keys on
replicas).

Next logical step in the example above is to remove key1 from replica 1 so you
will end replica1 having key2 and replica2 having only key1.

How can we guarantee that synchronization mechanism will not wipe key1 from
parent? Or the other way around? How can we guarantee that key2 was uploaded?

Also, things will break is number of keys in parent exceeds reasonable number
(because DNS replies will be to big etc.).


Proposal 1
==
- Store state and timestamps for (zone,key,replica) triplet
- Do state transition only if all triplets (zone,key,?) indicate that all
replicas reached desired state so the transition is safe.
- This implicitly means that no transition will happen if one or more
replicas
is down. This is necessary otherwise DNSSEC validation can break mysteriously
when keys got out of sync.

dn: cn=,ipk11Label=zone1_keyid123_private, cn=keys, cn=sec,
cn=dns, dc=example
idnssecKeyCreated: 
idnssecKeyPublished: 
idnssecKeyActivated: 
idnssecKeyInactivated: 
idnssecKeyDeleted: 


Why do you care for all 5 states ?

In short, to follow RFC 6781 and all it's requirements.


Simo and I have discussed this off-line. The final decision is to rely on
replication. The assumption is that if replication is broken, everything will
break soon anyway, so the original proposal is overkill.

We have to store one set of timestamps somewhere to be able to follow RFC
6781, so we decided to store it in the key-metadata object.

I added other attributes to object class definition so it contains all
necessary metadata. The new object class idnsSecKey is now complete.

Please note that DN in the previous example was incorrect. It is necessary to
store the metadata separately for pairs (zone, key) to cover the case where
key is shared between zones. This also nicely splits metadata from actual key
material.

All attributes are single-valued.
MUST attributes are:
  idnsSecKeyRef
  idnsSecKeyCreated
  idnsSecAlgorithm

dn: cn=, cn=keys, idnsname=example.com, cn=dns, dc=example
objectClass: idnsSecKey
idnsSecKeyRef: 
idnsSecKeyCreated: 
idnsSecKeyPublish: 
idnsSecKeyActivate: 
idnsSecKeyInactive: 
idnsSecKeyDelete: 
idnsSecKeyZone:  equivalent to bit 7 (ZONE) in [1]
idnsSecKeyRevoke:  equivalent to bit 8 (REVOKE) in [1]
idnsSecKeySep:  equivalent to bit 15 (SEP) in [1]
idnsSecAlgorithm:  used as mnemonic in [2]


I haven't heard any complains so I allocated OIDs and I'm going to implement it.

Petr^2 Spacek


[1]
http://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml#dnskey-flags-1
[2]
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1



It looks to me the only relevant states are Activated and (perhaps)
Deactivated.

But then again if replication is broken *many* other things are, so
should we *really* care to handle broken replication by adding all this
information ?

We need to keep track of timestamps anyway (to follow RFC 6781) so we need
some other way how to *make sure* that timestamps never go backwards, even if
replication was broken and later restarted.

What do you propose?


Effectively, state machine will be controlled by max(attribute) over all
replicas (for given key).

Replication traffic estimation
--
Number of writes to LDAP = (State transitions per key) * (Keys per zone) *
(Number of zones) * (Number of replicas)

The obvious

Re: [Freeipa-devel] [PATCH 0053] Implement OTP token importing

[Simo Sorce]

On Wed, 2014-06-18 at 17:34 -0400, Nathaniel McCallum wrote:
> On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote:
> > This patch adds support for importing tokens using RFC 6030 key
> > container files. This includes decryption support. For sysadmin sanity,
> > any tokens which fail to add will be written to the output file for
> > examination. The main use case here is where a small subset of a large
> > set of tokens fails to validate or add. Using the output file, the
> > sysadmin can attempt to recover these specific tokens.
> > 
> > This code is implemented as a server-side script. However, it doesn't
> > actually need to run on the server. This was done because importing is
> > an odd fit for the IPA command framework:
> > 1. We need to write an output file.
> > 2. The operation may be long-running (thousands of tokens).
> > 3. Only admins need to perform this task and it only happens
> > infrequently.
> 
> Attached is revision 4. I believe this addresses all the points given
> over the last few days in all emails. The ipa_otptoken_import.py has
> been significantly reworked to make it simpler and easy to test, but
> none of the logic has changed.
> 
> I have removed most of the inheritance and sorted out most of the style
> issues (like map() vs comprehension). I did not change the XML parsing
> because it appears that network access is disabled by default.
> 
> I have also included a test suite which should have 100% code coverage.
> It even tests for features we don't support yet (like X.509). All tests
> pass for me.
> 
> Nathaniel

+++ b/install/tools/man/ipa-otptoken-import.1
@@ -0,0 +1,36 @@
+.\" A man page for ipa-compat-manage

Bad Copy&paste here ^^^

Simo.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration

[Nathaniel McCallum]

On Wed, 2014-06-04 at 18:47 +0300, Alexander Bokovoy wrote:
> On Thu, 01 May 2014, Nathaniel McCallum wrote:
> >On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote:
> >> On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote:
> >> > On Tue, 11 Mar 2014, Jan Pazdziora wrote:
> >> > >On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote:
> >> > >> Before this patch, ipa-kdb would load global configuration on startup
> >> > >> and never update it. This means that if global configuration is 
> >> > >> changed,
> >> > >> the KDC never receives the new configuration until it is restarted.
> >> > >>
> >> > >> This patch enables caching of the global configuration with a timeout 
> >> > >> of
> >> > >> 60 seconds.
> >> > >>
> >> > >> https://fedorahosted.org/freeipa/ticket/4153
> >> > >
> >> > >> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 
> >> > >> >2001
> >> > >> From: Nathaniel McCallum 
> >> > >> Date: Mon, 24 Feb 2014 14:19:13 -0500
> >> > >> Subject: [PATCH] Periodically refresh global ipa-kdb configuration
> >> > >>
> >> > >> Before this patch, ipa-kdb would load global configuration on startup 
> >> > >> and
> >> > >> never update it. This means that if global configuration is changed, 
> >> > >> the
> >> > >> KDC never receives the new configuration until it is restarted.
> >> > >>
> >> > >> This patch enables caching of the global configuration with a timeout 
> >> > >> of
> >> > >> 60 seconds.
> >> > >>
> >> > >> https://fedorahosted.org/freeipa/ticket/4153
> >> > >
> >> > >I have only read the code and it looks sane, so depending on how much
> >> > >you consider my word about code-reading worth, ack.
> >> > >
> >> > >However, my gut feeling is that my preferred way of handling the issue
> >> > >(without knowing much about the background of the ticket) would
> >> > >probably be a HUP signal handler or something similar, rather than
> >> > >polling for current values with the value timeout. This patch
> >> > >introduces small nondeterminism to the behaviour when the usage of the
> >> > >new values cannot really be enfoced by the admin (without the daemon
> >> > >restart).
> >> > Thing is, we need the update to happen when other, non-root process
> >> > makes the changes -- in our case when IPA server running under httpd
> >> > privileges performs series of MS-RPC calls towards smbd which lead to
> >> > creating certain LDAP objects. httpd couldn't send SIGHUP to a process
> >> > not owned by httpd's effective user (non-root).
> >>
> >> Yes but this is not really the way to go.
> >>
> >> The proper fix is to use syncrepl/persistent search to get a
> >> notification of when we need to reload the configuration.
> >>
> >> On the patch itself I have a NACK due to this syntax used in various
> >> places: function()->attribute
> >>
> >> don't. do. that. ever.
> >>
> >> assign whatever come from the function to a local variable and *check*
> >> it is not null, *then* use it.
> >
> >Attached patch fixes the NACK issue, but does not address the question
> >of the larger approach. Do we need to take a different approach? If so,
> >what is it?
> 
> I've tested the patch but was unable to spot any activity to refresh the
> configuration after I've updated it with 
> ipa config-mod --ipaconfigstring=KDC:Disable\ Lockout
> 
> At least, dirsrv logs didn't show me any attempt to re-read IPA config
> past the change.

I spent extensive time testing this today. I am unable to reproduce a
failure to reload data from LDAP. If I make the change using "ipa
config-mod", wait a minute and run a kinit the KDC always gets the new
values. So it works for me.

However, I did uncover a subtle bug with regard to ipaconfigstring which
would cause it to never to be unset once set. Perhaps you were running
into this?

The new attached version fixes this bug. Everything appears to work...

Nathaniel
From 34bd5bd7f7e846ee302ff54891dc42e6ac777690 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum 
Date: Mon, 24 Feb 2014 14:19:13 -0500
Subject: [PATCH] Periodically refresh global ipa-kdb configuration

Before this patch, ipa-kdb would load global configuration on startup and
never update it. This means that if global configuration is changed, the
KDC never receives the new configuration until it is restarted.

This patch enables caching of the global configuration with a timeout of
60 seconds.

https://fedorahosted.org/freeipa/ticket/4153
---
 daemons/ipa-kdb/ipa_kdb.c| 82 +---
 daemons/ipa-kdb/ipa_kdb.h| 17 ++--
 daemons/ipa-kdb/ipa_kdb_audit_as.c   |  9 +++-
 daemons/ipa-kdb/ipa_kdb_mspac.c  | 10 -
 daemons/ipa-kdb/ipa_kdb_principals.c | 11 -
 5 files changed, 85 insertions(+), 44 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c
index 0f3996cdfa35374c005bc1ed174dea0816a27747..e5101bdd0ad880888fd58fd93a5ca8133868db98 100644
--- a/daemons/ipa-kdb/ipa_kdb.c
+++ b/daemons/ipa-kdb/ipa_kdb.c
@@ -25,6