date:20140528

On 05/27/2014 08:18 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:
On Tue, 27 May 2014, Simo Sorce wrote:
On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:
On 05/27/2014 06:56 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:
On 05/27/2014 06:06 PM, Simo Sorce wrote:
We just need to care about the 'uid' attribute in the staged entry, and
pick that to generate the RDN of the user in the active tree. If there
are conflicts the 'unstage' will fail cleanly, as the 'add' operation
will just fail (due to non unique RDN) and the admin will have to take
care of the situation.
In that case the provisioning system created a staging entry
ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE
It could be an issue for the provisioning system to retrieve the entry
it created.
Too bad for the provisioning system, we are not going to allow users to
have a form that does not use uid in the RDN in IPA.

yes that is correct.
Does it address the security concern, if the operator that is allowed to
add in 'staging'/'pre-active' is different from the one allowed to move
the entry in 'active' ?

Well it really depends on 'who' the operator is.

We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give priority
to getting the workflow right in terms of the way it works.

Right it allows us to do things like filter out objectclass or
attributes the provisioning system adds but that the admin does not want
in the final entry. This is not something we may want to build into the
solution from day zero, but it gives us the option to build it more
easily, as a framework filter on the 'unstage' operation.
(We so need to be able to copy additional objectclasses and their
attributes from day 0 though).
Simo.

Ok, thanks guys, I see an agreement. Thierry, we should now update all the
information here:

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

(you can even link this thread in the archives)

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

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.
From d4bd77e498156a976a81bf6c166069087bcb4d8a Mon Sep 17 00:00:00 2001
From: Ade Lee a...@redhat.com
Date: Tue, 15 Apr 2014 14:09:32 -0400
Subject: [PATCH] Added ipa-drm-install

ipa-drm-install can be used (with no arguments) to
add a DRM to an existing ipa instance that already contains
a Dogtag CA.

In a subsequent patch, I will add logic to this script to
detect if a drm naming context exists, and if so, to look for
a replica file for installing on a replica.
---
 freeipa.spec.in   |   2 +
 install/po/Makefile.in|   1 +
 install/tools/Makefile.am |   1 +
 install/tools/ipa-dns-install |   1 +
 install/tools/ipa-drm-install | 196 ++
 install/tools/ipa-upgradeconfig   |  67 +
 ipaserver/install/drminstance.py  |   4 +
 ipaserver/install/dsinstance.py   |  77 +++
 ipaserver/install/installutils.py |  23 +++--
 9 files changed, 296 insertions(+), 76 deletions(-)
 create mode 100644 install/tools/ipa-drm-install

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 
7ed989ec33a423646a5a3925894b52b85b101ec9..98782477857830d184aa48fb3792a94bf223b749
 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -145,6 +145,7 @@ Requires: selinux-policy = 3.12.1-135
 Requires(post): selinux-policy-base
 Requires: slapi-nis = 0.47.7
 Requires: pki-ca = 10.1.1
+Requires: pki-kra = 10.1.1
 Requires: dogtag-pki-server-theme
 %if 0%{?rhel}
 Requires: subscription-manager
@@ -646,6 +647,7 @@ fi
 %{_sbindir}/ipa-restore
 %{_sbindir}/ipa-ca-install
 %{_sbindir}/ipa-dns-install
+%{_sbindir}/ipa-drm-install
 %{_sbindir}/ipa-server-install
 %{_sbindir}/ipa-replica-conncheck
 %{_sbindir}/ipa-replica-install
diff --git a/install/po/Makefile.in b/install/po/Makefile.in
index 
6dca615c13acf8d40030da0318a1103f4ece1181..c8d7b6353e2b2b00f6e9e6f8cfe3bcc8f84ae73f
 100644
--- a/install/po/Makefile.in
+++ b/install/po/Makefile.in
@@ -47,6 +47,7 @@ PY_EXPLICIT_FILES = \
  install/tools/ipa-csreplica-manage \
  install/tools/ipactl \
  install/tools/ipa-dns-install \
+ install/tools/ipa-drm-install \
  install/tools/ipa-ldap-updater \
  install/tools/ipa-managed-entries \
  install/tools/ipa-nis-manage \
diff --git a/install/tools/Makefile.am b/install/tools/Makefile.am
index 
2cf66c6dfc1c272bb423253902e7339e7d159567..7f8e4a5a0217327662b57921314fcb03f60dc46c
 100644
--- a/install/tools/Makefile.am
+++ b/install/tools/Makefile.am
@@ -7,6 +7,7 @@ SUBDIRS =   \
 sbin_SCRIPTS = \
ipa-ca-install  \
ipa-dns-install \
+   ipa-drm-install \
ipa-server-install  \
ipa-adtrust-install \
ipa-replica-conncheck   \
diff --git a/install/tools/ipa-dns-install b/install/tools/ipa-dns-install
index 
78acc2d9bce02203cc97346b8797ec3ae40a3044..4684416685c06b919f3750f7a6cb064286b3b76d
 100755
--- a/install/tools/ipa-dns-install
+++ b/install/tools/ipa-dns-install
@@ -31,6 +31,7 @@ from ipapython import ipautil, sysrestore
 from ipalib import api, errors, util
 from ipapython.config import IPAOptionParser
 from ipapython.ipa_log_manager import standard_logging_setup, root_logger
+from ipapython.ipautil import DN
 
 log_file_name = /var/log/ipaserver-install.log
 
diff --git a/install/tools/ipa-drm-install b/install/tools/ipa-drm-install
new file mode 100644
index 
..7af39a3c749964d93a87bc4b58f1f41f8bc87269
--- /dev/null
+++ b/install/tools/ipa-drm-install
@@ -0,0 +1,196 @@
+#! /usr/bin/python2 -E
+# Authors: Ade Lee a...@redhat.com
+#
+# Copyright (C) 2014  Red Hat
+# see file 'COPYING' for use and warranty information
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with

[Freeipa-devel] running out of entropy during ipa-server-install

Hi all,

Today I hit the WARNING: Your system is running out of entropy, you
may experience long delays message while testing Ade's
ipa-server-install changes.

I got a lot more entropy a lot faster by installing haveged(8), and
I blogged about it here:
http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/

Do you think it would be worthwhile to update the above warning
message to additionally suggest installing haveged(8) or pointing to
other help on remediating a low-entropy system?

Cheers,

Fraser

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

Re: [Freeipa-devel] Supported Staged entries

2014-05-28 Thread thierry bordaz

On 05/28/2014 08:22 AM, Martin Kosek wrote:

On 05/27/2014 08:18 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:

On Tue, 27 May 2014, Simo Sorce wrote:

On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:

On 05/27/2014 06:56 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:

On 05/27/2014 06:06 PM, Simo Sorce wrote:

In that case the provisioning system created a staging entry
ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE
It could be an issue for the provisioning system to retrieve the entry
it created.

Too bad for the provisioning system, we are not going to allow users to
have a form that does not use uid in the RDN in IPA.

Sounds like a lot of complexity for a problem we do not really have, all
we need is to not enforce uniqueness in staging.

This proposal was also to limit the operator privilege to do MODRDN from
'pre-active' to 'active', instead ADD on 'active'.

It is not useful, the operator still needs to be able to create in
pre-active ... so it can still create what it wants.

yes that is correct.
Does it address the security concern, if the operator that is allowed to
add in 'staging'/'pre-active' is different from the one allowed to move
the entry in 'active' ?

Well it really depends on 'who' the operator is.

We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give priority
to getting the workflow right in terms of the way it works.

I agree. It also opens us a way to handle import of any foreign schema
person if staged object uses extensibleObject object class where we are
in control of what exactly will get into the actual tree.

Ok, thanks guys, I see an agreement. Thierry, we should now update all the
information here:

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

(you can even link this thread in the archives)

Martin

Yes I will do that.

Regarding workflow, it looks a priority that active entries are valid
(regarding FreeIPA).

Currently CLI offers:

* ipa user-add (in active)
* ipa user-add --stage (in stage).

In order to prevent admin to add a corrupted entry in active and force
any entry to go through the filter of objectclass/attribute, we could
make 'ipa user-add' to create entry in staging and 'ipa user-add
--active' to create entry in active. Even more, should we support to add
entry directly in 'active' or rather only support 'user-add' to go only
in staging ?

thanks
thierry

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

Re: [Freeipa-devel] running out of entropy during ipa-server-install


On 05/28/2014 09:06 AM, Fraser Tweedale wrote:

Hi all,

Today I hit the WARNING: Your system is running out of entropy, you
may experience long delays message while testing Ade's
ipa-server-install changes.

I got a lot more entropy a lot faster by installing haveged(8), and
I blogged about it here:
http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/

Do you think it would be worthwhile to update the above warning
message to additionally suggest installing haveged(8) or pointing to
other help on remediating a low-entropy system?

Cheers,

Fraser


Hello,
haveged is not the only solution. As you note there's also rngd; and 
with modern virtualization systems VMs can get entropy from the host. If 
we suggest a concrete solution we should be reasonably sure it's the 
best one.
AFAK, for RHEL/CentOS haveged is only in EPEL, we probably don't want to 
suggest it there.


--
Petr³




P.S. I use this hack for my testing VMs:
   https://copr.fedoraproject.org/coprs/pviktori/breakmycryptod/

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

Re: [Freeipa-devel] [PATCH 0257] Fix race condition during zone loading

2014-05-28 Thread Tomas Hozza

On 05/27/2014 03:59 PM, Petr Spacek wrote:
 On 27.5.2014 15:54, Petr Spacek wrote:
 Fix race condition during zone loading.

 DNS zone has to be added to DNS view before dns_zone_load() is called.
 It is necessary to prevent dns_zone_load() from racing with
 dns_zone_setview().

 This race condition sometimes prevents zone from being signed.
 Now the unsigned zone is visible until signing process is complete. This
 mimics BIND behavior for in-line signed zones.

 https://fedorahosted.org/bind-dyndb-ldap/ticket/56
 
 And here is the patch...
 

Hi.

When I use bind-dyndb-ldap plugin with this patch, named
does not start due to:

rbt.c:1379: REQUIRE(name-buffer != ((void *)0)) failed, back trace

(gdb) bt
#0  0x7f3963924c39 in raise () from /lib64/libc.so.6
#1  0x7f3963926348 in abort () from /lib64/libc.so.6
#2  0x7f3966979aee in assertion_failed ()
#3  0x7f3964b6917a in isc_assertion_failed () from /lib64/libisc.so.95
#4  0x7f39661ca9da in dns_rbt_fullnamefromnode () from
/lib64/libdns.so.100
#5  0x7f396011824b in rbt_iter_getnodename (iter=optimized out,
nodename=nodename@entry=0x7f39625f8bf0) at rbt_helper.c:46
#6  0x7f396011839b in rbt_iter_next
(iterp=iterp@entry=0x7f39625f8b90,
nodename=nodename@entry=0x7f39625f8bf0) at rbt_helper.c:144
#7  0x7f3960112d32 in activate_zones
(task=task@entry=0x7f39668f5790, inst=0x7f39668e4160) at ldap_helper.c:1164
#8  0x7f396011a20d in barrier_decrement (task=0x7f39668f5790,
event=0x7f396005b010) at syncrepl.c:138
#9  0x7f3964b8b836 in run () from /lib64/libisc.so.95
#10 0x7f396473ff33 in start_thread () from /lib64/libpthread.so.0
#11 0x7f39639e3ded in clone () from /lib64/libc.so.6


It looks like you should use INIT_BUFFERED_NAME(name); used in the
original code instead of dns_name_init(name, NULL). The macro
initializes the buffer in name, which is missing in the new code.


Regards,

Tomas

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

Re: [Freeipa-devel] running out of entropy during ipa-server-install

On 05/28/2014 12:08 PM, Petr Viktorin wrote:
 On 05/28/2014 09:06 AM, Fraser Tweedale wrote:
 Hi all,

 Today I hit the WARNING: Your system is running out of entropy, you
 may experience long delays message while testing Ade's
 ipa-server-install changes.

 I got a lot more entropy a lot faster by installing haveged(8), and
 I blogged about it here:
 http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/

 Do you think it would be worthwhile to update the above warning
 message to additionally suggest installing haveged(8) or pointing to
 other help on remediating a low-entropy system?

 Cheers,

 Fraser
 
 Hello,
 haveged is not the only solution. As you note there's also rngd; and with
 modern virtualization systems VMs can get entropy from the host. If we suggest
 a concrete solution we should be reasonably sure it's the best one.
 AFAK, for RHEL/CentOS haveged is only in EPEL, we probably don't want to
 suggest it there.
 

I think the key point here is that FreeIPA announces that the entropy is low
thus giving the administrator an option to do his homework on how to increase
entropy on my system - for example by reading Fraser's blog :-)

I also do not think that FreeIPA should give any more recommendations on top of
that.

Thanks,
Martin

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

Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...

On 04/16/2014 03:42 PM, Simo Sorce wrote:
 On Wed, 2014-04-16 at 14:55 +0200, Martin Kosek wrote:
 On 04/16/2014 02:49 PM, Petr Viktorin wrote:
 On 04/16/2014 02:45 PM, Simo Sorce wrote:
 On Wed, 2014-04-16 at 10:20 +0200, Petr Viktorin wrote:
 On 04/16/2014 10:02 AM, Martin Kosek wrote:
 I was looking into ticket
 https://fedorahosted.org/freeipa/ticket/4054
 and experimenting with ACIs allowing privileged users to manage only
 their own LDAP objects.

 As already proposed in the Bugzilla, I had success with following ACIs:

 
 # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123
 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test
 add: aci
 aci: (targetattr = userclass)(targetfilter =
 (objectclass=ipahost))(version 3.0;acl permission:Modify own
 hosts;allow (write) userattr = creatorsName#USERDN;)

 modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test

 # ldapmodify -h `hostname` -D cn=Directory Manager -x -w Secret123
 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test
 add: aci
 aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl
 permission:Modify own hosts;allow (delete) userattr =
 creatorsName#USERDN;)

 modifying entry cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test
 

 When I then added a user fbar with permission Add hosts, I was able to
 do exactly what proposed in the ticket:


 $ ipa host-add test.example.com --force
 -
 Added host test.example.com
 -
 Host name: test.example.com
 Principal name: host/test.example@mkosek-fedora20.test
 Password: False
 Keytab: False
 Managed by: test.example.com

 $ ipa host-mod test.example.com --class foo
 
 Modified host test.example.com
 
 Host name: test.example.com
 Principal name: host/test.example@mkosek-fedora20.test
 Class: foo
 Password: False
 Keytab: False
 Managed by: test.example.com

 $ ipa host-mod admin.example.com --class foo
 ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the
 'userClass' attribute of entry
 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'.


 $ ipa host-del admin.example.com
 ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to
 delete the entry
 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'.


 $ ipa host-del test.example.com
 ---
 Deleted host test.example.com
 ---

 I think this could be pretty powerful also with other LDAP objects.
 Question is what can be done to allow that to our users.

 I do not think we should add these ACIs by default as not everybody
 would like them. But if we enhance our permission API to allow the
 userattr bind rule, admins could add these ACIs at their wish.

 IMO the API is not that difficult, something like this could work:

 $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname
 --bind-attr-type=USERDN

 --bind-attr could be more or less free form text to allow creatorsname
 or parent[0].creatorsname
 --bind-attr-type would be enum of values USERDN/GROUPDN

 This should cover most of the basic use cases.

 Thoughts?


 Makes sense. I'd do it around the time we move self-service to 
 permissions.

 Simo, can you reserve two more OIDs for the attributes?

 What attributes ? userclass ? Can't we simply use a group/role ?

 The --bind-attr and --bind-attr-type values will need to be stored in the
 permission entry, so we'll need ipaPermBindAttr and ipaPermBindAttrType.

 I would personally wait with reserving OID until we create a design of this
 feature as there are several approaches. We could for example need one more
 attribute, ipaPermBindAttrDepth we would use for control of the ACI effective
 depth (mutli valued, values 0-4).
 
 Agreed, there is no hurry until we have a design page.
 
 simo.

I personally had a secret wish we could make this RFE happen in 4.0, but it is
too late for that - thus moving the ticket to 4.1.

Martin

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

Re: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin

On Mon, 2014-05-26 at 10:33 +0200, Martin Kosek wrote:
 freeipa-server-foreman-smartproxy#
 [ 40%]

It works for me.
I install 3.5, upgrade to 4.0 and it works

-- 
Martin^2 Basti

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

Re: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin

On 05/28/2014 01:50 PM, Martin Basti wrote:
 On Mon, 2014-05-26 at 10:33 +0200, Martin Kosek wrote:
 freeipa-server-foreman-smartproxy#
 [ 40%]
 
 It works for me.
 I install 3.5, upgrade to 4.0 and it works
 

Ok, thanks for testing - I might have improperly updated the patches.

Just grepping through code, I am thinking the following part of bindinstance.py
may still cause a crash:

cnames = get_rr(domain_name, IPA_CA_RECORD, CNAME)
if not cnames:
return

root_logger.info('Converting IPA CA CNAME records to A/ records')

# create CNAME to FQDN mapping
cname_fqdn = {}
for cname in cnames:
if cname.endswith('.'):
fqdn = cname[:-1]
else:


You can easily test that with patched 4.0 by removing ipa-ca DNS A records,
replacing with CNAMEs pointing to IPA FQDN and running ipa-upgradeconfig.

My best bet is that it will crash badly.

Martin

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

Re: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin

On Wed, 2014-05-28 at 13:56 +0200, Martin Kosek wrote:
 On 05/28/2014 01:50 PM, Martin Basti wrote:
  On Mon, 2014-05-26 at 10:33 +0200, Martin Kosek wrote:
  freeipa-server-foreman-smartproxy#
  [ 40%]
  
  It works for me.
  I install 3.5, upgrade to 4.0 and it works
  
 
 Ok, thanks for testing - I might have improperly updated the patches.
 
 Just grepping through code, I am thinking the following part of 
 bindinstance.py
 may still cause a crash:
 
 cnames = get_rr(domain_name, IPA_CA_RECORD, CNAME)
 if not cnames:
 return
 
 root_logger.info('Converting IPA CA CNAME records to A/ records')
 
 # create CNAME to FQDN mapping
 cname_fqdn = {}
 for cname in cnames:
 if cname.endswith('.'):
 fqdn = cname[:-1]
 else:
 
 
 You can easily test that with patched 4.0 by removing ipa-ca DNS A records,
 replacing with CNAMEs pointing to IPA FQDN and running ipa-upgradeconfig.
 
 My best bet is that it will crash badly.
 
 Martin

I will take a look.

Also here is a rebased patch, because API minor version was changed.
-- 
Martin^2 Basti
From a9a727c2c9816a467503e1e991bedecd140a498d Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Fri, 11 Apr 2014 14:45:43 +0200
Subject: [PATCH] dns_name_values capability added

Added capability to transfer DNSName type between server and client

Part of ticket:
IPA should allow internationalized domain names
https://fedorahosted.org/freeipa/ticket/3169i
---
 API.txt|  1 +
 VERSION|  4 ++--
 ipalib/capabilities.py |  5 -
 ipalib/rpc.py  | 23 ---
 4 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/API.txt b/API.txt
index 1ea93e9dd403c3fe1a8ca6b047d6fee72220a862..49fde8e86f63e48b02a01bbb8d027ac831ed 100644
--- a/API.txt
+++ b/API.txt
@@ -4011,3 +4011,4 @@ capability: optional_uid_params 2.54
 capability: permissions2 2.69
 capability: primary_key_types 2.83
 capability: datetime_values 2.84
+capability: dns_name_values 2.87
diff --git a/VERSION b/VERSION
index 87e67cf7ac1dcac333980ae7ed5b41921d48c966..c450b3427d64a6e37a381997cb9247247ab19ae1 100644
--- a/VERSION
+++ b/VERSION
@@ -89,5 +89,5 @@ IPA_DATA_VERSION=2010061412
 #  #
 
 IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=86
-# Last change: npmccallum - Only specify the ipatokenuniqueid default in the add operation
+IPA_API_VERSION_MINOR=87
+# Last change: mbasti - Added 'dns_name_values' capability
diff --git a/ipalib/capabilities.py b/ipalib/capabilities.py
index f2e45a0f66f596b23ed36c0e2c38ddc79e8625d7..5533bf72ef7999bec8594aa9bf8d7437a6c19a21 100644
--- a/ipalib/capabilities.py
+++ b/ipalib/capabilities.py
@@ -50,7 +50,10 @@ capabilities = dict(
 primary_key_types=u'2.83',
 
 # support for datetime values on the client
-datetime_values=u'2.84'
+datetime_values=u'2.84',
+
+# dns_name_values: dnsnames as objects
+dns_name_values=u'2.87',
 )
 
 
diff --git a/ipalib/rpc.py b/ipalib/rpc.py
index c44ffb6e19f452006d7dcf0a89f0644efb0aea01..f48a494811a104f08e03417568f318e80e485732 100644
--- a/ipalib/rpc.py
+++ b/ipalib/rpc.py
@@ -60,6 +60,7 @@ from ipapython.ipa_log_manager import root_logger
 from ipapython import ipautil
 from ipapython import kernel_keyring
 from ipapython.cookie import Cookie
+from ipapython.dnsutil import DNSName
 from ipalib.text import _
 from ipapython.nsslib import NSSHTTPS, NSSConnection
 from ipalib.krb_utils import KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN, KRB5KRB_AP_ERR_TKT_EXPIRED, \
@@ -173,6 +174,12 @@ def xml_wrap(value, version):
 else:
 return value.strftime(LDAP_GENERALIZED_TIME_FORMAT)
 
+if isinstance(value, DNSName):
+if capabilities.client_has_capability(version, 'dns_name_values'):
+return {'__dns_name__': unicode(value)}
+else:
+return unicode(value)
+
 assert type(value) in (unicode, int, long, float, bool, NoneType)
 return value
 
@@ -198,9 +205,12 @@ def xml_unwrap(value, encoding='UTF-8'):
 if type(value) in (list, tuple):
 return tuple(xml_unwrap(v, encoding) for v in value)
 if type(value) is dict:
-return dict(
-(k, xml_unwrap(v, encoding)) for (k, v) in value.iteritems()
-)
+if '__dns_name__' in value:
+return DNSName(value['__dns_name__'])
+else:
+return dict(
+(k, xml_unwrap(v, encoding)) for (k, v) in value.iteritems()
+)
 if type(value) is str:
 return value.decode(encoding)
 if isinstance(value, Binary):
@@ -284,6 +294,11 @@ def json_encode_binary(val, version):
 return {'__datetime__': val.strftime(LDAP_GENERALIZED_TIME_FORMAT)}
 else:
 return val.strftime(LDAP_GENERALIZED_TIME_FORMAT)
+

Re: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin

On Wed, 2014-05-28 at 13:56 +0200, Martin Kosek wrote:
 On 05/28/2014 01:50 PM, Martin Basti wrote:
  On Mon, 2014-05-26 at 10:33 +0200, Martin Kosek wrote:
  freeipa-server-foreman-smartproxy#
  [ 40%]
  
  It works for me.
  I install 3.5, upgrade to 4.0 and it works
  
 
 Ok, thanks for testing - I might have improperly updated the patches.
 
 Just grepping through code, I am thinking the following part of 
 bindinstance.py
 may still cause a crash:
 
 cnames = get_rr(domain_name, IPA_CA_RECORD, CNAME)
 if not cnames:
 return
 
 root_logger.info('Converting IPA CA CNAME records to A/ records')
 
 # create CNAME to FQDN mapping
 cname_fqdn = {}
 for cname in cnames:
 if cname.endswith('.'):
 fqdn = cname[:-1]
 else:
 
 
 You can easily test that with patched 4.0 by removing ipa-ca DNS A records,
 replacing with CNAMEs pointing to IPA FQDN and running ipa-upgradeconfig.
 
 My best bet is that it will crash badly.
 
 Martin

CNAME record is returned as string, so this is no issue (tested)
-- 
Martin^2 Basti

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

Re: [Freeipa-devel] [PATCH] 0557 pwpolicy-mod: Fix crash when priority is changed

On 05/27/2014 01:27 PM, Petr Viktorin wrote:
 See the ticket  commit message.
 
 https://fedorahosted.org/freeipa/ticket/4309


Yup, this fixed the crash. ACK!

Martin

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

Re: [Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone

On 05/26/2014 12:48 PM, Petr Viktorin wrote:
 On 05/14/2014 12:50 PM, Petr Viktorin wrote:
 On 04/30/2014 10:00 AM, thierry bordaz wrote:
 On 04/29/2014 10:07 PM, Martin Kosek wrote:
 On 04/29/2014 08:17 PM, Simo Sorce wrote:
 On Tue, 2014-04-29 at 20:00 +0200, Petr Viktorin wrote:
 This adds the idnsSecInlineSigning attribute and related option.

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

 Simo, is adding a MAY attribute to an existing objectClass okay?


 Not unheard of, however in the past we discovered some schema
 replication issues that may have an impact, let's make sure DS team
 also
 agrees this is not going to cause issue.

 From a purely functional pov a MAY attribute will not break any stored
 object, so it is fine.

 Simo.

 Adding Thierry to the CC list to evaluate the risks, he was already
 involved in fixing related issue in the DS for a similar Dogtag schema
 extension.
 Hello,

 When an instance in the topology contains schema extensions like new
 MAY attribute, this extension would be propagated to all instances
 by replication (no need to copy/merge schema files). This was the
 purpose of https://fedorahosted.org/389/ticket/47721. So it is fine
 to add new MAY/MUST attribute or new attribute/objectclasses.

 During a replication session, a master will check what schema
 definitions (objectclasses/attributes) of the replica extends its
 own schema. If such definitions exist the supplier add/replace them
 in its schema and its user99.ldif file. In your case if a replica
 contains a new allowed attribute (e.g. 'idnsSecInlineSigning') but
 not the supplier then the supplier 'learns it' (during a replication
 session it initiated) and so an entry containing that new attribute
 can be updated on the supplier as well.
 There is a similar mechanism, when a replica receives a schema that
 contains new definitions, it 'learns' them.

 The fix for 47721 is introduced in 389-ds 1.3.2.17 and after.
 It was tested with mixing 1.3.2.17 instance with legacy versions
 (1.3.1, 1,3.0..), and the schema on both side converged to a common
 one. This, whatever if the extensions are present on both side.
 A limitation is that a legacy instance (not having the fix), must
 have a replica agreements to/from an instance with the fix.

 regards
 thierry


 Thanks. This means the patch is good for review.
 I've just rebased it slightly.
 
 Another rebase in VERSION was necessary.
 Still looking for a review.

This is pretty obvious change, worked fine for me. ACK!

Martin

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

Re: [Freeipa-devel] Supported Staged entries

On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:
On 05/28/2014 08:22 AM, Martin Kosek wrote:
On 05/27/2014 08:18 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:
On Tue, 27 May 2014, Simo Sorce wrote:
On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:
On 05/27/2014 06:56 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:
On 05/27/2014 06:06 PM, Simo Sorce wrote:
We just need to care about the 'uid' attribute in the staged entry,
and
pick that to generate the RDN of the user in the active tree. If
there
are conflicts the 'unstage' will fail cleanly, as the 'add' operation
will just fail (due to non unique RDN) and the admin will have to
take
care of the situation.
In that case the provisioning system created a staging entry
ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE
It could be an issue for the provisioning system to retrieve the entry
it created.
Too bad for the provisioning system, we are not going to allow users to
have a form that does not use uid in the RDN in IPA.

Sounds like a lot of complexity for a problem we do not really have,
all
we need is to not enforce uniqueness in staging.
This proposal was also to limit the operator privilege to do MODRDN
from
'pre-active' to 'active', instead ADD on 'active'.
It is not useful, the operator still needs to be able to create in
pre-active ... so it can still create what it wants.
yes that is correct.
Does it address the security concern, if the operator that is allowed to
add in 'staging'/'pre-active' is different from the one allowed to move
the entry in 'active' ?
Well it really depends on 'who' the operator is.

We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give priority
to getting the workflow right in terms of the way it works.

I think re-creating the user object gives us better chances at handling
the overall workflow and fixing up entries accordingly to the management
framework view of what a user needs to look like, so in the end I prefer
that route.
I agree. It also opens us a way to handle import of any foreign schema
person if staged object uses extensibleObject object class where we are
in control of what exactly will get into the actual tree.
Right it allows us to do things like filter out objectclass or
attributes the provisioning system adds but that the admin does not want
in the final entry. This is not something we may want to build into the
solution from day zero, but it gives us the option to build it more
easily, as a framework filter on the 'unstage' operation.
(We so need to be able to copy additional objectclasses and their
attributes from day 0 though).
Simo.
Ok, thanks guys, I see an agreement. Thierry, we should now update all the
information here:

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

(you can even link this thread in the archives)

Martin
Yes I will do that.

Regarding workflow, it looks a priority that active entries are valid
(regarding FreeIPA).
Currently CLI offers:

* ipa user-add (in active)
* ipa user-add --stage (in stage).

I do not see why this would ever be necessary, ipa user-add cannot
create a corrupt entry by definition.

Simo.

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

Re: [Freeipa-devel] Supported Staged entries

2014-05-28 Thread Rob Crittenden

Simo Sorce wrote:
On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:
On 05/28/2014 08:22 AM, Martin Kosek wrote:
On 05/27/2014 08:18 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:
On Tue, 27 May 2014, Simo Sorce wrote:
On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:
On 05/27/2014 06:56 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:
On 05/27/2014 06:06 PM, Simo Sorce wrote:
We just need to care about the 'uid' attribute in the staged entry,
and
pick that to generate the RDN of the user in the active tree. If
there
are conflicts the 'unstage' will fail cleanly, as the 'add' operation
will just fail (due to non unique RDN) and the admin will have to
take
care of the situation.
In that case the provisioning system created a staging entry
ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE
It could be an issue for the provisioning system to retrieve the entry
it created.
Too bad for the provisioning system, we are not going to allow users to
have a form that does not use uid in the RDN in IPA.

We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give priority
to getting the workflow right in terms of the way it works.

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

(you can even link this thread in the archives)

Martin
Yes I will do that.

Regarding workflow, it looks a priority that active entries are valid
(regarding FreeIPA).
Currently CLI offers:

* ipa user-add (in active)
* ipa user-add --stage (in stage).

I do not see why this would ever be necessary, ipa user-add cannot
create a corrupt entry by definition.

I'm not sure what the use case for this is either, other than
simplifying testing. If you have access to the IPA API then why bother
staging a user?

rob

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

Re: [Freeipa-devel] Supported Staged entries

2014-05-28 Thread thierry bordaz

On 05/28/2014 02:55 PM, Rob Crittenden wrote:

Simo Sorce wrote:

On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:

On 05/28/2014 08:22 AM, Martin Kosek wrote:

On 05/27/2014 08:18 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:

On Tue, 27 May 2014, Simo Sorce wrote:

On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:

On 05/27/2014 06:56 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:

On 05/27/2014 06:06 PM, Simo Sorce wrote:

Too bad for the provisioning system, we are not going to allow users to
have a form that does not use uid in the RDN in IPA.

Sounds like a lot of complexity for a problem we do not really have, all
we need is to not enforce uniqueness in staging.

This proposal was also to limit the operator privilege to do MODRDN from
'pre-active' to 'active', instead ADD on 'active'.

It is not useful, the operator still needs to be able to create in
pre-active ... so it can still create what it wants.

yes that is correct.
Does it address the security concern, if the operator that is allowed to
add in 'staging'/'pre-active' is different from the one allowed to move
the entry in 'active' ?

Well it really depends on 'who' the operator is.

We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give priority
to getting the workflow right in terms of the way it works.

Ok, thanks guys, I see an agreement. Thierry, we should now update all the
information here:

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

(you can even link this thread in the archives)

Martin

Yes I will do that.

Regarding workflow, it looks a priority that active entries are valid
(regarding FreeIPA).
Currently CLI offers:

* ipa user-add (in active)
* ipa user-add --stage (in stage).

I do not see why this would ever be necessary, ipa user-add cannot
create a corrupt entry by definition.

I'm not sure what the use case for this is either, other than
simplifying testing. If you have access to the IPA API then why bother
staging a user?

rob

I agree, FreeIPA CLI or API will create valid entry.

Now a staging area can be used for storing entries waiting for an
approval. For an example, a cron job scanning the stage container may
send request to an approver. The approver having the ability to read the
'stage' entry will issue 'ipa user-unstage' or not.

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

[Freeipa-devel] [PATCHES] 0558-0561 Read ACI fixes


Hello,
Some of IPA plugins assume that everyone has access to everything. Here 
are some fixes for that.


Patch 0560 adds a new permission for the UPG Definition, which is 
required to add users correctly.


--
Petr³
From 1846d12939dbfc209aeca30820642d1565da6fd1 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Tue, 27 May 2014 16:22:33 +0200
Subject: [PATCH] krbtpolicy plugin: Fix internal error when global policy is
 not readable

Part of the work for: https://fedorahosted.org/freeipa/ticket/4354
---
 ipalib/plugins/krbtpolicy.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ipalib/plugins/krbtpolicy.py b/ipalib/plugins/krbtpolicy.py
index 22a961a4ab6005b138d0fb261d2a90527b373c48..252e4f96b56cf7a0977e33d72094599eabb2f46c 100644
--- a/ipalib/plugins/krbtpolicy.py
+++ b/ipalib/plugins/krbtpolicy.py
@@ -175,9 +175,10 @@ def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
 # if policy for a specific user isn't set, display global values
 if 'krbmaxticketlife' not in entry_attrs or \
 'krbmaxrenewableage' not in entry_attrs:
-res = self.api.Command.krbtpolicy_show()
+res = self.api.Command.krbtpolicy_show()['result']
 for a in self.obj.default_attributes:
-entry_attrs.setdefault(a, res['result'][a])
+if a in res:
+entry_attrs.setdefault(a, res[a])
 return dn
 
 api.register(krbtpolicy_show)
-- 
1.9.0

From 16b9037aaed75d522ee625266137a54d34ace153 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Tue, 27 May 2014 16:41:43 +0200
Subject: [PATCH] aci plugin: Fix internal error when ACIs are not readable

Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
 ipalib/plugins/aci.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipalib/plugins/aci.py b/ipalib/plugins/aci.py
index 4821089f164106f195e9c59d5c9a379d8ffadf27..158909837040a4f43c50bf0e36ae62f2c61041e6 100644
--- a/ipalib/plugins/aci.py
+++ b/ipalib/plugins/aci.py
@@ -546,7 +546,7 @@ def execute(self, aciname, **kw):
 raise errors.DuplicateEntry()
 
 newaci_str = unicode(newaci)
-entry['aci'].append(newaci_str)
+entry.setdefault('aci', []).append(newaci_str)
 
 if not kw.get('test', False):
 ldap.update_entry(entry)
-- 
1.9.0

From 8907407b9237cfc834c0423724011cbb1394c10c Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 28 May 2014 12:42:02 +0200
Subject: [PATCH] Add managed read permission for the UPG Definition

Since user_add checks the UPG definition to see if UPG is enabled,
user admins need read access to add users correctly.

All attributes are allowed since UPG Definition is an extensibleObject;
the needed attributes are not in the schema.

Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
 ipalib/plugins/user.py | 17 +
 1 file changed, 17 insertions(+)

diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py
index 604502ee77bc7d10a951335b423526949154392b..27ad36b7fdbee5b2c0dba10f1c381233e8059150 100644
--- a/ipalib/plugins/user.py
+++ b/ipalib/plugins/user.py
@@ -111,6 +111,12 @@
 ),
)
 
+UPG_DEFINITION_DN = DN(('cn', 'UPG Definition'),
+   ('cn', 'Definitions'),
+   ('cn', 'Managed Entries'),
+   ('cn', 'etc'),
+   api.env.basedn)
+
 # characters to be used for generating random user passwords
 user_pwdchars = string.digits + string.ascii_letters + '_,.@+-='
 
@@ -319,6 +325,17 @@ class user(LDAPObject):
 'memberof',
 },
 },
+'System: Read UPG Definition': {
+# Required for adding users
+'replaces_global_anonymous_aci': True,
+'non_object': True,
+'ipapermlocation': UPG_DEFINITION_DN,
+'ipapermtarget': UPG_DEFINITION_DN,
+'ipapermbindruletype': 'permission',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {'*'},
+'default_privileges': {'User Administrators'},
+},
 }
 
 label = _('Users')
-- 
1.9.0

From 12616b75d28a61d7d8c4066ba6061aeda76a71a9 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Tue, 27 May 2014 17:07:13 +0200
Subject: [PATCH] ldap2.has_upg: Raise an error if the UPG definition is not
 found

The UPG Definition is always present in IPA; if it can not be read
it's usually caused by insufficient privileges.
Previously the code assumed the absence of the entry meant that
UPG is disabled. With granular read permissions, this would mean
that users that can add users but can't read UPG Definition would
add users without UPG, and the reason for that would not be very clear.
It is better to fail early if the definition can't be read.

Raise

Re: [Freeipa-devel] Supported Staged entries

On 05/28/2014 02:48 PM, Simo Sorce wrote:
On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:
On 05/28/2014 08:22 AM, Martin Kosek wrote:
On 05/27/2014 08:18 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:
On Tue, 27 May 2014, Simo Sorce wrote:
On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:
On 05/27/2014 06:56 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:
On 05/27/2014 06:06 PM, Simo Sorce wrote:
We just need to care about the 'uid' attribute in the staged entry,
and
pick that to generate the RDN of the user in the active tree. If
there
are conflicts the 'unstage' will fail cleanly, as the 'add' operation
will just fail (due to non unique RDN) and the admin will have to
take
care of the situation.
In that case the provisioning system created a staging entry
ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE
It could be an issue for the provisioning system to retrieve the entry
it created.
Too bad for the provisioning system, we are not going to allow users to
have a form that does not use uid in the RDN in IPA.

We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give priority
to getting the workflow right in terms of the way it works.

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

(you can even link this thread in the archives)

Martin
Yes I will do that.

Regarding workflow, it looks a priority that active entries are valid
(regarding FreeIPA).
Currently CLI offers:

* ipa user-add (in active)
* ipa user-add --stage (in stage).

I do not see why this would ever be necessary, ipa user-add cannot
create a corrupt entry by definition.

Simo.

/me wishes that the major concerns were spelled out during initial RFE review...

Could this help a custom provisioning system that uses FreeIPA user-add
JSON-RPC command instead of ldapadd? The record may still be incomplete in
terms of company policy (e.g. missing manager) and about to be moved only when
the user joins the company?

Or is this nonsense and we should avoid doing user-add/user-mod/user-del in the
staging area?

Martin

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

Re: [Freeipa-devel] [PATCH] 0557 pwpolicy-mod: Fix crash when priority is changed


On 05/28/2014 02:44 PM, Martin Kosek wrote:

On 05/27/2014 01:27 PM, Petr Viktorin wrote:

See the ticket  commit message.

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



Yup, this fixed the crash. ACK!

Martin



Thanks, pushed to master: 8bbd52e347f3e6395d469528e1220fd9158e5609

--
Petr³

___
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


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.

--
Petr³

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

Re: [Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone


On 05/28/2014 02:45 PM, Martin Kosek wrote:

On 05/26/2014 12:48 PM, Petr Viktorin wrote:

On 05/14/2014 12:50 PM, Petr Viktorin wrote:

On 04/30/2014 10:00 AM, thierry bordaz wrote:

On 04/29/2014 10:07 PM, Martin Kosek wrote:

On 04/29/2014 08:17 PM, Simo Sorce wrote:

On Tue, 2014-04-29 at 20:00 +0200, Petr Viktorin wrote:

This adds the idnsSecInlineSigning attribute and related option.

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

Simo, is adding a MAY attribute to an existing objectClass okay?



Not unheard of, however in the past we discovered some schema
replication issues that may have an impact, let's make sure DS team
also
agrees this is not going to cause issue.


 From a purely functional pov a MAY attribute will not break any stored

object, so it is fine.

Simo.


Adding Thierry to the CC list to evaluate the risks, he was already
involved in fixing related issue in the DS for a similar Dogtag schema
extension.

Hello,

 When an instance in the topology contains schema extensions like new
 MAY attribute, this extension would be propagated to all instances
 by replication (no need to copy/merge schema files). This was the
 purpose of https://fedorahosted.org/389/ticket/47721. So it is fine
 to add new MAY/MUST attribute or new attribute/objectclasses.

 During a replication session, a master will check what schema
 definitions (objectclasses/attributes) of the replica extends its
 own schema. If such definitions exist the supplier add/replace them
 in its schema and its user99.ldif file. In your case if a replica
 contains a new allowed attribute (e.g. 'idnsSecInlineSigning') but
 not the supplier then the supplier 'learns it' (during a replication
 session it initiated) and so an entry containing that new attribute
 can be updated on the supplier as well.
 There is a similar mechanism, when a replica receives a schema that
 contains new definitions, it 'learns' them.

 The fix for 47721 is introduced in 389-ds 1.3.2.17 and after.
 It was tested with mixing 1.3.2.17 instance with legacy versions
 (1.3.1, 1,3.0..), and the schema on both side converged to a common
 one. This, whatever if the extensions are present on both side.
 A limitation is that a legacy instance (not having the fix), must
 have a replica agreements to/from an instance with the fix.

 regards
 thierry



Thanks. This means the patch is good for review.
I've just rebased it slightly.


Another rebase in VERSION was necessary.
Still looking for a review.


This is pretty obvious change, worked fine for me. ACK!

Martin



Thanks, pushed to master: 8b7daf675e77d7a5e2de6eadb26ca3b682c0d67f

--
Petr³

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

Re: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user


On 05/27/2014 05:13 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 18:01 +0300, Alexander Bokovoy wrote:

On Tue, 27 May 2014, Petr Viktorin wrote:

On 05/26/2014 12:13 PM, Petr Viktorin wrote:
[...]


Thanks for the thorough review!
Pushed to master: 63becae88c6c270b98f0432dc474b661b82f3119



Okay guys, we have another issue:
user-add (and the migration plugin) needs access to cn=UPG
Definition,cn=Definitions,cn=Managed Entries,cn=etc,... to check the
originfilter for '(objectclass=disable)'.

Do we want to give read access to all users, or just user admins?

I would say user admins. If something more substantial fails, we'll
extend the access.



ACK



For the record, the change is in my patch 0560.

--
Petr³

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

Re: [Freeipa-devel] Supported Staged entries

On 05/28/2014 03:06 PM, thierry bordaz wrote:
On 05/28/2014 02:55 PM, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:
On 05/28/2014 08:22 AM, Martin Kosek wrote:
On 05/27/2014 08:18 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:
On Tue, 27 May 2014, Simo Sorce wrote:
On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:
On 05/27/2014 06:56 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:
On 05/27/2014 06:06 PM, Simo Sorce wrote:
We just need to care about the 'uid' attribute in the staged entry,
and
pick that to generate the RDN of the user in the active tree. If
there
are conflicts the 'unstage' will fail cleanly, as the 'add'
operation
will just fail (due to non unique RDN) and the admin will have to
take
care of the situation.
In that case the provisioning system created a staging entry
ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE
It could be an issue for the provisioning system to retrieve the
entry
it created.
Too bad for the provisioning system, we are not going to allow users
to
have a form that does not use uid in the RDN in IPA.

Sounds like a lot of complexity for a problem we do not really
have, all
we need is to not enforce uniqueness in staging.
This proposal was also to limit the operator privilege to do MODRDN
from
'pre-active' to 'active', instead ADD on 'active'.
It is not useful, the operator still needs to be able to create in
pre-active ... so it can still create what it wants.
yes that is correct.
Does it address the security concern, if the operator that is allowed
to
add in 'staging'/'pre-active' is different from the one allowed to
move
the entry in 'active' ?
Well it really depends on 'who' the operator is.

We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give
priority
to getting the workflow right in terms of the way it works.

I think re-creating the user object gives us better chances at handling
the overall workflow and fixing up entries accordingly to the
management
framework view of what a user needs to look like, so in the end I
prefer
that route.
I agree. It also opens us a way to handle import of any foreign schema
person if staged object uses extensibleObject object class where we are
in control of what exactly will get into the actual tree.
Right it allows us to do things like filter out objectclass or
attributes the provisioning system adds but that the admin does not want
in the final entry. This is not something we may want to build into the
solution from day zero, but it gives us the option to build it more
easily, as a framework filter on the 'unstage' operation.
(We so need to be able to copy additional objectclasses and their
attributes from day 0 though).
Simo.
Ok, thanks guys, I see an agreement. Thierry, we should now update all the
information here:

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

(you can even link this thread in the archives)

Martin
Yes I will do that.

Regarding workflow, it looks a priority that active entries are valid
(regarding FreeIPA).
Currently CLI offers:

* ipa user-add (in active)
* ipa user-add --stage (in stage).

I am actually not very happy with the ipa user-add --stage idea, the
staging area is necessary for when you do not create a full 'ipa' user
entry, but rather for when a provisioning system creates an incomplete
entry.
I'm not sure what the use case for this is either, other than
simplifying testing. If you have access to the IPA API then why bother
staging a user?

rob

I agree, FreeIPA CLI or API will create valid entry.

Now a staging area can be used for storing entries waiting for an approval.
For
an example, a cron job scanning the stage container may send request to an
approver. The approver having the ability to read the 'stage' entry will issue
'ipa user-unstage' or not.

thanks
thierry

Right. Company/app may for example have a registration page where users can
fill their personal details. The page would only have privilege to add staged
users. Unstaging would then be made after

Re: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions

On 05/27/2014 04:20 PM, Martin Kosek wrote:

On 05/26/2014 04:44 PM, Petr Viktorin wrote:

On 05/22/2014 03:07 PM, Petr Viktorin wrote:

Hello,
Here I start upgrading the existing default permissions to the new
Managed style.

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

The patches rely on my patch 0551
(https://fedorahosted.org/freeipa/ticket/4349)
You may run into what seems to be a 389 bug. If you get a Midair
Collision (NO_SUCH_ATTRIBUTE) error, restart the DS and try running
ipa-ldap-updater again. I'm working with Ludwig on this one.

The operation is now described at
http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions

If there user has modified an old default permission, a warning is
logged the replacement permission is not added/updated. The user needs
to evaluate the situation: either update the old permission to match the
original default, or remove the old permission, and then run
ipa-ldap-updater will create the new one.
Is bailing out the right thing to do if the old entry was modified?

Forcing user to remove old permission and create new one seems as a too much
work to me. After the upgrade, we need to be sure that the managed permissions
is there.

Note that this only happens if the user changed the permissions, so we
need to be extra careful to respect their wishes.

What is the problem of having both 2 permissions in the DS? The old modified
permission and the new system managed one? As we are dealing with allow
permissions, having 2 of them should be harmless.

The new one could be granting too much access, the admin might have
wanted to restrict the defaults.

It could be possible to parse the permission, figure out the changes the
user made, and apply them to the new one, but that seems like too much
guesswork to me.

Maybe we could do the same we do with managed permissions upgrades? Only allow
differences in the list of attributes? I am thinking that people could hotfix
missing attributes at permissions themselves (like adding description to
sudorule permission), this would lead to duplicate permissions later.

What we could do when old ACI differs only in allowed attributes is to compare
it to defaults and set whitelist and blacklist attributes of the new managed
permission. Then we can safely delete the old ACI (with warning).

If you think this is too much work, we can keep the old behavior and just add
duplicate ACI.

Having duplicate permissions would be possible, after all they have a
different name. However I'd expect that most people would still want to
delete the old ones, rather than letting them hide among user-defined
permissions.

On the other hand, my approach has a downside as well: if the
'memberallowcmd' attribute was removed from 'Modify Sudo rule', there's
now no way to upgrade while allowing access but keeping that attribute
off-limits, short of writing deny a ACI by hand. How big a problem is
this? It might be worth it to create a special tool that upgrades a
single permission and allows setting the excluded/included attributes
explicitly.

This problem would be removed with my approach proposed above.

There are some interesting scenarios to think about with respect to
upgrades and user changes:

* Upgrade to old version, e.g.
- have IPA 3.2 master, IPA 3.2 replica
- upgrade master to 4.0 (old permissions are updated)
- then upgrade replica to 3.3 (old permissions are added again!)

This is AFAIK not supported but it does happen.
We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will
always add the old permissions, but with this patch, a subsequent
upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the old
permissions again.

Hm, I think this is the best option we have. We should warn about this behavior
in our release notes though.

Tied to that is another scenario:

* Re-create permissions with old names
- have IPA 4.0 master
- Create a permission named 'Modify Sudo rule'
- Upgrade to IPA 4.1

Here we need to make sure the new permission is *not* removed, because a
new 'Modify Sudo rule' permission is no longer special in any way. To
ensure this the updater only removes old-style permissions.

Right, we can decide based on objectclasses - whether permissionsv2 OC is there
or not.

One thing that can happen when 4.0 masters are still mixed with 3.x is
that an old permission named 'Modify Sudo rule' is added on the old
server. Any update to 4.0+ will remove that.
Old-style default permissions were sorta-kinda managed by IPA itself
anyway, so users should expect this. We should still point it out in the
docs though, since I expect some users to start messing with the
permissions before upgrading all of the infrastructure to 4.0.

+1, I would just point out that behavior in the release notes.

The second patch upgrades sudorule permissions, this server as an
example of how the will work.
The third patch fixes

Re: [Freeipa-devel] Supported Staged entries

On Wed, 2014-05-28 at 15:56 +0200, Martin Kosek wrote:
On 05/28/2014 02:48 PM, Simo Sorce wrote:
On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:
On 05/28/2014 08:22 AM, Martin Kosek wrote:
On 05/27/2014 08:18 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:
On Tue, 27 May 2014, Simo Sorce wrote:
On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:
On 05/27/2014 06:56 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:
On 05/27/2014 06:06 PM, Simo Sorce wrote:
We just need to care about the 'uid' attribute in the staged
entry, and
pick that to generate the RDN of the user in the active tree. If
there
are conflicts the 'unstage' will fail cleanly, as the 'add'
operation
will just fail (due to non unique RDN) and the admin will have to
take
care of the situation.
In that case the provisioning system created a staging entry
ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE
It could be an issue for the provisioning system to retrieve the
entry
it created.
Too bad for the provisioning system, we are not going to allow users
to
have a form that does not use uid in the RDN in IPA.

Sounds like a lot of complexity for a problem we do not really
have, all
we need is to not enforce uniqueness in staging.
This proposal was also to limit the operator privilege to do MODRDN
from
'pre-active' to 'active', instead ADD on 'active'.
It is not useful, the operator still needs to be able to create in
pre-active ... so it can still create what it wants.
yes that is correct.
Does it address the security concern, if the operator that is allowed
to
add in 'staging'/'pre-active' is different from the one allowed to
move
the entry in 'active' ?
Well it really depends on 'who' the operator is.

We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give
priority
to getting the workflow right in terms of the way it works.

I think re-creating the user object gives us better chances at handling
the overall workflow and fixing up entries accordingly to the
management
framework view of what a user needs to look like, so in the end I
prefer
that route.
I agree. It also opens us a way to handle import of any foreign schema
person if staged object uses extensibleObject object class where we are
in control of what exactly will get into the actual tree.
Right it allows us to do things like filter out objectclass or
attributes the provisioning system adds but that the admin does not want
in the final entry. This is not something we may want to build into the
solution from day zero, but it gives us the option to build it more
easily, as a framework filter on the 'unstage' operation.
(We so need to be able to copy additional objectclasses and their
attributes from day 0 though).
Simo.
Ok, thanks guys, I see an agreement. Thierry, we should now update all the
information here:

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

(you can even link this thread in the archives)

Martin
Yes I will do that.

Regarding workflow, it looks a priority that active entries are valid
(regarding FreeIPA).
Currently CLI offers:

* ipa user-add (in active)
* ipa user-add --stage (in stage).

I do not see why this would ever be necessary, ipa user-add cannot
create a corrupt entry by definition.

Simo.

/me wishes that the major concerns were spelled out during initial RFE
review...

Or is this nonsense and we should avoid doing user-add/user-mod/user-del in
the
staging area?

Note that I did not say we should not have an IPA command for that, but
I dislike the idea of putting it in the user plugin and using that
specific

Re: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions

On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote:
 Simo, I hazily remember discussing that we should only allow specific 
 attributes on add, otherwise users can add entries with any extra 
 objectclasses and attributes. Did we come to a conclusion?
 I might have confused targetattr with targetattrfilter in my notes; 
 since I see targetarr is ineffective.
 
Yes we need to restrict at least the allowed objectclasses I think.

Simo.

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

Re: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions

On 05/28/2014 04:50 PM, Simo Sorce wrote:
 On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote:
 Simo, I hazily remember discussing that we should only allow specific 
 attributes on add, otherwise users can add entries with any extra 
 objectclasses and attributes. Did we come to a conclusion?
 I might have confused targetattr with targetattrfilter in my notes; 
 since I see targetarr is ineffective.

 Yes we need to restrict at least the allowed objectclasses I think.
 
 Simo.
 

We do not have a support for targetattrfilter, I do not think this was ever
tested. This part of ACI is also not very well documented, I think Petr found
just one notice in the DS documentation about targetattrfilter.

For 4.0, I would keep the add ACIs as they area (we do not have time for
additional experiments anyway). If we feel the urge later, given the
permissions are managed, it should be easy to change that.

Martin

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

Re: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions

2014-05-28 Thread Ludwig Krispenz



On 05/28/2014 04:56 PM, Martin Kosek wrote:

On 05/28/2014 04:50 PM, Simo Sorce wrote:

On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote:

Simo, I hazily remember discussing that we should only allow specific
attributes on add, otherwise users can add entries with any extra
objectclasses and attributes. Did we come to a conclusion?
I might have confused targetattr with targetattrfilter in my notes;
since I see targetarr is ineffective.


Yes we need to restrict at least the allowed objectclasses I think.

Simo.


We do not have a support for targetattrfilter, I do not think this was ever
tested. This part of ACI is also not very well documented, I think Petr found
just one notice in the DS documentation about targetattrfilter.
It is in chapter 13.2.3.5 in 
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Targets

and it is for unknown reasons: targattrfilters


For 4.0, I would keep the add ACIs as they area (we do not have time for
additional experiments anyway). If we feel the urge later, given the
permissions are managed, it should be easy to change that.

Martin


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

Re: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions

On 05/28/2014 05:03 PM, Ludwig Krispenz wrote:

On 05/28/2014 04:56 PM, Martin Kosek wrote:
On 05/28/2014 04:50 PM, Simo Sorce wrote:
On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote:
Simo, I hazily remember discussing that we should only allow specific
attributes on add, otherwise users can add entries with any extra
objectclasses and attributes. Did we come to a conclusion?
I might have confused targetattr with targetattrfilter in my notes;
since I see targetarr is ineffective.

Yes we need to restrict at least the allowed objectclasses I think.

Simo.

We do not have a support for targetattrfilter, I do not think this was ever
tested. This part of ACI is also not very well documented, I think Petr found
just one notice in the DS documentation about targetattrfilter.
It is in chapter 13.2.3.5 in
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Targets

and it is for unknown reasons: targattrfilters

Right, this is what I (and Petr) was talking about. The doc contain just this
single one line of information about targetattrfilters. Try googling that and
you won't get much more.

Just for completeness, posting one of the top findings:

Bug 1032767 - Examples of the targetattrfilters ACI keyword need to be
documented

Martin

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

Re: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions

2014-05-28 Thread Ludwig Krispenz

On 05/28/2014 05:08 PM, Martin Kosek wrote:

On 05/28/2014 05:03 PM, Ludwig Krispenz wrote:

On 05/28/2014 04:56 PM, Martin Kosek wrote:

On 05/28/2014 04:50 PM, Simo Sorce wrote:

On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote:

Simo, I hazily remember discussing that we should only allow specific
attributes on add, otherwise users can add entries with any extra
objectclasses and attributes. Did we come to a conclusion?
I might have confused targetattr with targetattrfilter in my notes;
since I see targetarr is ineffective.

Yes we need to restrict at least the allowed objectclasses I think.

Simo.

It is in chapter 13.2.3.5 in
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Targets

and it is for unknown reasons: targattrfilters

Right, this is what I (and Petr) was talking about. The doc contain just this
single one line of information about targetattrfilters.

Well, it is not much, but more than one line :-)

13.3.2.5. Targeting Attribute Values Using LDAP Filters

You can use access control to target specific attribute values. This
means that you can grant or deny permissions on an attribute if that
attribute's value meets the criteria defined in the ACI. An ACI that
grants or denies access based on an attribute's value is called a
value-based ACI.
For example, you might grant all users in your organization permission
to modify the /|nsroledn|/ attribute in their own entry. However, you
would also want to ensure that they do not give themselves certain key
roles, such as |Top Level Administrator|. LDAP filters are used to
check that the conditions on attribute values are satisfied.
To create a value-based ACI, you must use the |targattrfilters|
keyword with the following syntax:
(targattrfilters=add=attr1:F1 attr2:F2... attrn:Fn,del=attr1:F1
/|attr2|/:/|F2|/ ... /|attrn|/:/|Fn|/)

*
|add| represents the operation of creating an attribute.
*
|del| represents the operation of deleting an attribute.
*
/attrx/ represents the target attributes.
*
/Fx/ represents filters that apply only to the associated attribute.

When creating an entry, if a filter applies to an attribute in the new
entry, then each instance of that attribute must satisfy the filter.
When deleting an entry, if a filter applies to an attribute in the
entry, then each instance of that attribute must also satisfy the filter.
When modifying an entry, if the operation adds an attribute, then the
add filter that applies to that attribute must be satisfied; if the
operation deletes an attribute, then the delete filter that applies to
that attribute must be satisfied. If individual values of an attribute
already present in the entry are replaced, then both the add and
delete filters must be satisfied.

For example, consider the following attribute filter:
(targattrfilters=add=nsroledn:(!(nsroledn=cn=superAdmin))
telephoneNumber:(telephoneNumber=123*))
This filter can be used to allow users to add any role (/|nsroledn|/
attribute) to their own entry, except the |superAdmin| role. It also
allows users to add a telephone number with a 123 prefix.

*
*

Try googling that and
you won't get much more.

Just for completeness, posting one of the top findings:

Bug 1032767 - Examples of the targetattrfilters ACI keyword need to be
documented

Martin

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

Re: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions

On 05/28/2014 05:13 PM, Ludwig Krispenz wrote:

On 05/28/2014 05:08 PM, Martin Kosek wrote:
On 05/28/2014 05:03 PM, Ludwig Krispenz wrote:
On 05/28/2014 04:56 PM, Martin Kosek wrote:
On 05/28/2014 04:50 PM, Simo Sorce wrote:
On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote:
Simo, I hazily remember discussing that we should only allow specific
attributes on add, otherwise users can add entries with any extra
objectclasses and attributes. Did we come to a conclusion?
I might have confused targetattr with targetattrfilter in my notes;
since I see targetarr is ineffective.

Yes we need to restrict at least the allowed objectclasses I think.

Simo.

We do not have a support for targetattrfilter, I do not think this was ever
tested. This part of ACI is also not very well documented, I think Petr
found
just one notice in the DS documentation about targetattrfilter.
It is in chapter 13.2.3.5 in
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Targets

and it is for unknown reasons: targattrfilters
Right, this is what I (and Petr) was talking about. The doc contain just this
single one line of information about targetattrfilters.
Well, it is not much, but more than one line :-)

Ah, I see, that's much better. The problem was that the guide is referring to
targattrfilters and not targetattrfilters - thus my CTRL+F searching method
failed :-).

I added a note to the referred Bugzilla.

Martin

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

Re: [Freeipa-devel] [PATCHES] 0052-0055 Separate master and forward DNS zones to separate objectClasses

On Wed, 2014-05-28 at 18:48 +0200, Martin Basti wrote:
 Ticket: https://fedorahosted.org/freeipa/ticket/3210
 Patches attached.
 
 TODO: upgrade procedure
 http://www.freeipa.org/page/V4/Forward_zones#Updates_and_Upgrades
 
 WebUI ticket: https://fedorahosted.org/freeipa/ticket/4357
 
 ___
 Freeipa-devel mailing list
 Freeipa-devel@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-devel

I forgot mention:
* Required patches: mbasti 0029-0032, 0034-0040, 0047,
0041-0042, 0045-0046

* For testing you will need to update schema:
Add line 

objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME 'idnsForwardZone' DESC
'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive
) MAY ( idnsForwarders $ idnsForwardPolicy ) )

into /etc/dirsrv/slapd-$REALM/schema/60ipadns.ldif and restart dirsrv

-- 
Martin^2 Basti

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

Re: [Freeipa-devel] Supported Staged entries

2014-05-28 Thread Rob Crittenden

Simo Sorce wrote:
On Wed, 2014-05-28 at 15:56 +0200, Martin Kosek wrote:
On 05/28/2014 02:48 PM, Simo Sorce wrote:
On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:
On 05/28/2014 08:22 AM, Martin Kosek wrote:
On 05/27/2014 08:18 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:
On Tue, 27 May 2014, Simo Sorce wrote:
On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:
On 05/27/2014 06:56 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:
On 05/27/2014 06:06 PM, Simo Sorce wrote:
We just need to care about the 'uid' attribute in the staged
entry, and
pick that to generate the RDN of the user in the active tree. If
there
are conflicts the 'unstage' will fail cleanly, as the 'add'
operation
will just fail (due to non unique RDN) and the admin will have to
take
care of the situation.
In that case the provisioning system created a staging entry
ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE
It could be an issue for the provisioning system to retrieve the
entry
it created.
Too bad for the provisioning system, we are not going to allow users
to
have a form that does not use uid in the RDN in IPA.

Sounds like a lot of complexity for a problem we do not really
have, all
we need is to not enforce uniqueness in staging.
This proposal was also to limit the operator privilege to do MODRDN
from
'pre-active' to 'active', instead ADD on 'active'.
It is not useful, the operator still needs to be able to create in
pre-active ... so it can still create what it wants.
yes that is correct.
Does it address the security concern, if the operator that is allowed
to
add in 'staging'/'pre-active' is different from the one allowed to
move
the entry in 'active' ?
Well it really depends on 'who' the operator is.

We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give
priority
to getting the workflow right in terms of the way it works.

I think re-creating the user object gives us better chances at handling
the overall workflow and fixing up entries accordingly to the
management
framework view of what a user needs to look like, so in the end I
prefer
that route.
I agree. It also opens us a way to handle import of any foreign schema
person if staged object uses extensibleObject object class where we are
in control of what exactly will get into the actual tree.
Right it allows us to do things like filter out objectclass or
attributes the provisioning system adds but that the admin does not want
in the final entry. This is not something we may want to build into the
solution from day zero, but it gives us the option to build it more
easily, as a framework filter on the 'unstage' operation.
(We so need to be able to copy additional objectclasses and their
attributes from day 0 though).
Simo.
Ok, thanks guys, I see an agreement. Thierry, we should now update all the
information here:

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

(you can even link this thread in the archives)

Martin
Yes I will do that.

Regarding workflow, it looks a priority that active entries are valid
(regarding FreeIPA).
Currently CLI offers:

* ipa user-add (in active)
* ipa user-add --stage (in stage).

I do not see why this would ever be necessary, ipa user-add cannot
create a corrupt entry by definition.

Simo.

/me wishes that the major concerns were spelled out during initial RFE
review...

Or is this nonsense and we should avoid doing user-add/user-mod/user-del in
the
staging area?

Note that I did not say we should not have an IPA command for that, but
I dislike the idea of putting it in the user plugin and using that
specific command expression.

I would see something like ipa stage-user-add username as a

Re: [Freeipa-devel] [PATCH 0257] Fix race condition during zone loading

2014-05-28 Thread Petr Spacek


On 28.5.2014 13:26, Tomas Hozza wrote:

On 05/27/2014 03:59 PM, Petr Spacek wrote:

On 27.5.2014 15:54, Petr Spacek wrote:

Fix race condition during zone loading.

DNS zone has to be added to DNS view before dns_zone_load() is called.
It is necessary to prevent dns_zone_load() from racing with
dns_zone_setview().

This race condition sometimes prevents zone from being signed.
Now the unsigned zone is visible until signing process is complete. This
mimics BIND behavior for in-line signed zones.

https://fedorahosted.org/bind-dyndb-ldap/ticket/56


And here is the patch...



Hi.

When I use bind-dyndb-ldap plugin with this patch, named
does not start due to:

rbt.c:1379: REQUIRE(name-buffer != ((void *)0)) failed, back trace

(gdb) bt
#0  0x7f3963924c39 in raise () from /lib64/libc.so.6
#1  0x7f3963926348 in abort () from /lib64/libc.so.6
#2  0x7f3966979aee in assertion_failed ()
#3  0x7f3964b6917a in isc_assertion_failed () from /lib64/libisc.so.95
#4  0x7f39661ca9da in dns_rbt_fullnamefromnode () from
/lib64/libdns.so.100
#5  0x7f396011824b in rbt_iter_getnodename (iter=optimized out,
nodename=nodename@entry=0x7f39625f8bf0) at rbt_helper.c:46
#6  0x7f396011839b in rbt_iter_next
(iterp=iterp@entry=0x7f39625f8b90,
nodename=nodename@entry=0x7f39625f8bf0) at rbt_helper.c:144
#7  0x7f3960112d32 in activate_zones
(task=task@entry=0x7f39668f5790, inst=0x7f39668e4160) at ldap_helper.c:1164
#8  0x7f396011a20d in barrier_decrement (task=0x7f39668f5790,
event=0x7f396005b010) at syncrepl.c:138
#9  0x7f3964b8b836 in run () from /lib64/libisc.so.95
#10 0x7f396473ff33 in start_thread () from /lib64/libpthread.so.0
#11 0x7f39639e3ded in clone () from /lib64/libc.so.6


It looks like you should use INIT_BUFFERED_NAME(name); used in the
original code instead of dns_name_init(name, NULL). The macro
initializes the buffer in name, which is missing in the new code.


Oh yes, it didn't happened on my machine because I have had only single zone 
defined in LDAP at the time of testing. Thank you for catching this!


I'm attaching fixed patch. dns_name_reset() is good enough in this case.

--
Petr^2 Spacek
From 2be7e3201f11e1322309534ab6762d637c8642c1 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Tue, 27 May 2014 15:41:59 +0200
Subject: [PATCH] Fix race condition during zone loading.

DNS zone has to be added to DNS view before dns_zone_load() is called.
It is necessary to prevent dns_zone_load() from racing with dns_zone_setview().

This race condition sometimes prevents zone from being signed.
Now the unsigned zone is visible until signing process is complete. This
mimics BIND behavior for in-line signed zones.

https://fedorahosted.org/bind-dyndb-ldap/ticket/56

Signed-off-by: Petr Spacek pspa...@redhat.com
---
 src/ldap_helper.c | 97 ++-
 src/ldap_helper.h |  2 +-
 2 files changed, 54 insertions(+), 45 deletions(-)

diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 3150b56f118b6270bb79a8bc2491c472b98477dc..b285d548d9a4ccbfb008ff024d4b6281315c629f 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -1100,65 +1100,74 @@ cleanup:
 }
 
 /**
+ * Add zone to view and call dns_zone_load().
+ */
+static isc_result_t ATTR_NONNULLS ATTR_CHECKRESULT
+activate_zone(isc_task_t *task, ldap_instance_t *inst, dns_name_t *name) {
+	isc_result_t result;
+	dns_zone_t *raw = NULL;
+	dns_zone_t *secure = NULL;
+	dns_zone_t *toview = NULL;
+	settings_set_t *zone_settings = NULL;
+
+	CHECK(zr_get_zone_ptr(inst-zone_register, name, raw, secure));
+
+	/* Load only secure zone if inline-signing is active.
+	 * It will not work if raw zone is loaded explicitly
+	 * - dns_zone_load() will fail magically. */
+	toview = (secure != NULL) ? secure : raw;
+
+	/*
+	 * Zone has to be published *before* zone load
+	 * otherwise it will race with zone-view != NULL check
+	 * in zone_maintenance() in zone.c.
+	 */
+	result = publish_zone(task, inst, toview);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(toview, ISC_LOG_ERROR,
+			 cannot add zone to view: %s,
+			 dns_result_totext(result));
+		goto cleanup;
+	}
+
+	CHECK(load_zone(toview));
+	if (secure != NULL) {
+		CHECK(zr_get_zone_settings(inst-zone_register, name,
+	   zone_settings));
+		CHECK(zone_master_reconfigure_nsec3param(zone_settings,
+			 secure));
+	}
+
+cleanup:
+	if (raw != NULL)
+		dns_zone_detach(raw);
+	if (secure != NULL)
+		dns_zone_detach(secure);
+	return result;
+}
+
+/**
  * Add all zones in zone register to DNS view specified in inst-view
  * and load zones.
  */
 isc_result_t
 activate_zones(isc_task_t *task, ldap_instance_t *inst) {
 	isc_result_t result;
-	isc_boolean_t loaded;
 	rbt_iterator_t *iter = NULL;
-	dns_zone_t *raw = NULL;
-	dns_zone_t *secure = NULL;
-	dns_zone_t *toview = NULL;
 	DECLARE_BUFFERED_NAME(name);
 	unsigned int published_cnt = 0;
 	unsigned int total_cnt = 0;
-	settings_set_t *zone_settings = NULL;

Re: [Freeipa-devel] running out of entropy during ipa-server-install

On Wed, May 28, 2014 at 01:38:05PM +0200, Martin Kosek wrote:
 On 05/28/2014 12:08 PM, Petr Viktorin wrote:
  On 05/28/2014 09:06 AM, Fraser Tweedale wrote:
  Hi all,
 
  Today I hit the WARNING: Your system is running out of entropy, you
  may experience long delays message while testing Ade's
  ipa-server-install changes.
 
  I got a lot more entropy a lot faster by installing haveged(8), and
  I blogged about it here:
  http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/
 
  Do you think it would be worthwhile to update the above warning
  message to additionally suggest installing haveged(8) or pointing to
  other help on remediating a low-entropy system?
 
  Cheers,
 
  Fraser
  
  Hello,
  haveged is not the only solution. As you note there's also rngd; and with
  modern virtualization systems VMs can get entropy from the host. If we 
  suggest
  a concrete solution we should be reasonably sure it's the best one.
  AFAK, for RHEL/CentOS haveged is only in EPEL, we probably don't want to
  suggest it there.
  
 
 I think the key point here is that FreeIPA announces that the entropy is low
 thus giving the administrator an option to do his homework on how to increase
 entropy on my system - for example by reading Fraser's blog :-)
 
 I also do not think that FreeIPA should give any more recommendations on top 
 of
 that.
 
 Thanks,
 Martin

Fair enough; all good points.  Thanks for the feedback.

Fraser

___
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

On Wed, May 28, 2014 at 03:53:01PM +0200, 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:
 

Cool, I didn't know about `git am`s 3-way merge capability.  The
resolution is trivial so I'll leave it at that.  Still an ACK for
patches 0002..0005 inclusive :)

 $ 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.
 
 -- 
 Petr³

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

Re: [Freeipa-devel] User life cycle: plugins scope for staged users


On 05/22/2014 10:33 AM, thierry bordaz wrote:

Hello,

In order to provision staged users (account inactivated) with
there initial values:

/usr/bin/ipa user-add tb20 --to-stage --first=tb20 --last=tb20
-
Added user tb20
-
  User login: tb20
  First name: tb20
  Last name: tb20
  Full name: tb20 tb20
  Display name: tb20 tb20
  Initials: tt
  Home directory: /home/tb20
  GECOS: tb20 tb20
  Login shell: /bin/sh
  Kerberos principal: t...@idm.lab.bos.redhat.com
  Email address: t...@idm.lab.bos.redhat.com
  UID: -1
  GID: -1
  Account disabled: true
  Password: False
  Kerberos keys available: False

ldapsearch -LLL -h localhost -p 389 -D cn=directory manager
-w Secret123 -b dc=idm,dc=lab,dc=bos,dc=redhat,dc=com uid=tb20
dn: uid=tb20,cn=staged
users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,
 dc=redhat,dc=com
displayName: tb20 tb20
cn: tb20 tb20
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
loginShell: /bin/sh
uidNumber: -1
ipaUniqueID: autogenerate
gidNumber: -1
gecos: tb20 tb20
sn: tb20
homeDirectory: /home/tb20
uid: tb20
mail: t...@idm.lab.bos.redhat.com
krbPrincipalName: t...@idm.lab.bos.redhat.com
givenName: tb20
initials: tt

I needed to resctrict the scope of the following plugins:

dn: cn=ipaUniqueID uniqueness,cn=plugins,cn=config
nsslapd-pluginarg1:
cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com

dn: cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=confi
ipauuidscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com

dn: cn=Posix IDs,cn=Distributed Numeric Assignment
Plugin,cn=plugins,cn=config
dnaScope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com

dn: cn=MemberOf Plugin,cn=plugins,cn=config
memberofentryscope:
cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com

In fact I need them to not modify the added entry when it is added
under cn=staged users,cn=accounts,cn=provisioning,$SUFFIX.
Now is it possible to limit those plugins scope to the
'cn=accounts' part of the tree ? I guess not.
If it is not possible, a solution is to make the scope
multi-valued attributes or to introduce a new config attribute
'*notInScope' also multi-valued.
A problem is the 'cn=ipaUniqueID uniqueness' that rely on the
'attribute uniqueness' plugin with a argv[ ], not really
convenient to pass 2 multivalued attributes.

If anyone is having others solutions it would help me a lot :-)

thanks
thierry




The easiest solution IMO is to not treat staging area as an account 
area, i.e instead of cn=staging, cn=accounts, dc=... I suggest saving 
users in cn=users, cn=staging, dc=...
This way if in future we will have some staging for other objects (for 
whatever reason) we will create containers under common staging area.

I would also argue that deleted should not be under accounts.








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



--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

Re: [Freeipa-devel] Supported Staged entries

On 05/27/2014 12:39 PM, thierry bordaz wrote:

On 05/27/2014 06:06 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 17:55 +0200, thierry bordaz wrote:

On 05/27/2014 04:35 PM, Martin Kosek wrote:

On 05/27/2014 04:27 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote:

This topic was already discussed in the past, see following part of
the design:

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

One of the biggest concern was that to allow operator unstage a
user,

he would
need to have a delete ACI in staging container AND add ACI in the
active users
area - which would also allow him to create any user he wishes in
the

users area.

This is the reason why we preferred to do and control it via MODRDN
and the
reason why Thierry implemented the new ACI for controlling MODRDN
operation:

https://fedorahosted.org/389/ticket/47553

I know that's why we did it, but I had a hard look since then, and I
believe we cannot really use that method.

The reason is simply that we do not control who adds the user
object and

our reason to do the staging is to make it simple for an external
provisioning system to create a basic user entry the way it knows how
to, with only the attributes the provisioning system cares about.

But this means we have no guarantee of what objectclasses are
available

on the object, so we have no guarantees all the necessary structureal
objectclasses have been added in the staging object.

We have to recreate the user object in order to be able to add all
the

right structural objectclasses as those can only be added at object
creation time in an LDAPv3 compliant LDAP server.

Both approach looks possible:

* adding required structural OC+AT in the existing entry
* creating a new entry with all structural OC+AT and update the AT
values with what exists in the stage entry

but I think the second one would be simpler to implement.

My assessment too.

Here again uid uniqueness is a difficulty: if 'uid' exists in stage
entry we need to delete the stage entry before adding the active one.
There is a risk to loose the entry if the add fails. Also it is
important to apply DEL/ADD on the same replica so that DEL csn ADD
csn.

I think the solution is to not have the uid uniqueness plugin look into
the staging tree. I think it is fair to put the burden of not creatoing
conflicting uids in the provisioning system the drives creating the
staged entries.

If a staged entry has a conflicting uid then at unstaging time we will
throw an error and the admin will have to fix the staged entry (either
remove it and ask the provisioning people to re-provision, or modifying
it).

Ok great.

Recreating the object will also allow you to deal with the other case
you brought forward where the provisioning system used CN as the RDN,
but we want uid.

I am not sure: if some provisioning systems created the two entries

# entry 1
dn: ou=TestUser,cn=staged
users,cn=accounts,cn=provisioning,dc=example,dc=com

objectClass: top
objectClass: account
uid: xxx
ou: TestUser

# entry 2
dn: uid=TestUser,cn=staged
users,cn=accounts,cn=provisioning,dc=example,dc=com

objectClass: top
objectClass: posixAccount
cn: TestUser
uid: TestUser
ipaUniqueID: autogenerate
uidNumber: -1
gidNumber: -1

If we activate both entries. we will create a new entry with all the
required objectclass but at the end we will need to pick up a 'uid'
value.
Entry 2 will keep its 'uid'. Entry 1 we have two solutions, 'xxx'
but then it changes the RDN value or 'TestUser' (the former RDN
value) that is in collision with entry 2.

I think it would simplify the problem if we enforce that staged
entries have 'uid' RDN.

To be honest I do not see the problem.

We just need to care about the 'uid' attribute in the staged entry, and
pick that to generate the RDN of the user in the active tree. If there
are conflicts the 'unstage' will fail cleanly, as the 'add' operation
will just fail (due to non unique RDN) and the admin will have to take
care of the situation.
In that case the provisioning system created a staging entry
ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE
It could be an issue for the provisioning system to retrieve the entry
it created.

I understand it gives operators a higher privilege, but I think we'll
have to think harder how to properly handle the issue.

A possibility is to create a pre-active status, between 'stage' and
'active'.
The 'stage' container contains raw provisioned entries. 'pre-active' a
copy of the 'stage' entry with all the structural objectclasses.

If 'pre-active' is out of the scope of uid uniqueness, we can add the
'pre-active' entry before removing the 'stage' entry (and rollback in
case of failure). Then do a MODRDN (with appropriate aci) 'pre-active'
- 'active'.

Sounds like a lot of complexity for a problem we do not really have, all
we need is to not enforce uniqueness in staging.

This proposal

Re: [Freeipa-devel] Supported Staged entries

On 05/28/2014 01:18 PM, Rob Crittenden wrote:

Simo Sorce wrote:

On Wed, 2014-05-28 at 15:56 +0200, Martin Kosek wrote:

On 05/28/2014 02:48 PM, Simo Sorce wrote:

On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:

On 05/28/2014 08:22 AM, Martin Kosek wrote:

On 05/27/2014 08:18 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:

On Tue, 27 May 2014, Simo Sorce wrote:

On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:

On 05/27/2014 06:56 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:

On 05/27/2014 06:06 PM, Simo Sorce wrote:

Too bad for the provisioning system, we are not going to allow users to
have a form that does not use uid in the RDN in IPA.

Sounds like a lot of complexity for a problem we do not really have, all
we need is to not enforce uniqueness in staging.

This proposal was also to limit the operator privilege to do MODRDN from
'pre-active' to 'active', instead ADD on 'active'.

It is not useful, the operator still needs to be able to create in
pre-active ... so it can still create what it wants.

yes that is correct.
Does it address the security concern, if the operator that is allowed to
add in 'staging'/'pre-active' is different from the one allowed to move
the entry in 'active' ?

Well it really depends on 'who' the operator is.

We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give priority
to getting the workflow right in terms of the way it works.

Ok, thanks guys, I see an agreement. Thierry, we should now update all the
information here:

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

(you can even link this thread in the archives)

Martin

Yes I will do that.

Regarding workflow, it looks a priority that active entries are valid
(regarding FreeIPA).
Currently CLI offers:

* ipa user-add (in active)
* ipa user-add --stage (in stage).

I do not see why this would ever be necessary, ipa user-add cannot
create a corrupt entry by definition.

Simo.

/me wishes that the major concerns were spelled out during initial RFE review...

Or is this nonsense and we should avoid doing user-add/user-mod/user-del in the
staging area?

Note that I did not say we should not have an IPA command for that, but
I dislike the idea of putting it in the user plugin and using that
specific command expression.

I would see something like ipa stage-user-add username as a better way
to go, in its own stage plugin.

This fits

Re: [Freeipa-devel] Supported Staged entries

On 05/28/2014 10:50 PM, Dmitri Pal wrote:

On 05/28/2014 01:18 PM, Rob Crittenden wrote:

Simo Sorce wrote:

On Wed, 2014-05-28 at 15:56 +0200, Martin Kosek wrote:

On 05/28/2014 02:48 PM, Simo Sorce wrote:

On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:

On 05/28/2014 08:22 AM, Martin Kosek wrote:

On 05/27/2014 08:18 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:

On Tue, 27 May 2014, Simo Sorce wrote:

On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:

On 05/27/2014 06:56 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:

On 05/27/2014 06:06 PM, Simo Sorce wrote:
We just need to care about the 'uid' attribute in the
staged entry, and
pick that to generate the RDN of the user in the active
tree. If there
are conflicts the 'unstage' will fail cleanly, as the
'add' operation
will just fail (due to non unique RDN) and the admin will
have to take

care of the situation.

In that case the provisioning system created a staging entry
ou=TestUser,$STAGING, it will get an active entry
uid=xxx,$ACTIVE
It could be an issue for the provisioning system to
retrieve the entry

it created.
Too bad for the provisioning system, we are not going to
allow users to

have a form that does not use uid in the RDN in IPA.

Sounds like a lot of complexity for a problem we do not
really have, all

we need is to not enforce uniqueness in staging.
This proposal was also to limit the operator privilege to
do MODRDN from

'pre-active' to 'active', instead ADD on 'active'.
It is not useful, the operator still needs to be able to
create in

pre-active ... so it can still create what it wants.

yes that is correct.
Does it address the security concern, if the operator that
is allowed to
add in 'staging'/'pre-active' is different from the one
allowed to move

the entry in 'active' ?

Well it really depends on 'who' the operator is.

We would like to be able to allow a 'junior admin/helpdesk
person' to
just press a button to activate a user, but that shouldn't
drive our

design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to
give priority

to getting the workflow right in terms of the way it works.

that route.
I agree. It also opens us a way to handle import of any
foreign schema
person if staged object uses extensibleObject object class
where we are

in control of what exactly will get into the actual tree.

easily, as a framework filter on the 'unstage' operation.
(We so need to be able to copy additional objectclasses and their
attributes from day 0 though).
Simo.
Ok, thanks guys, I see an agreement. Thierry, we should now
update all the

information here:

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP

(you can even link this thread in the archives)

Martin

Yes I will do that.

Regarding workflow, it looks a priority that active entries are
valid

(regarding FreeIPA).
Currently CLI offers:

* ipa user-add (in active)
* ipa user-add --stage (in stage).

In order to prevent admin to add a corrupted entry in active and
force
any entry to go through the filter of objectclass/attribute, we
could

make 'ipa user-add' to create entry in staging and 'ipa user-add
--active' to create entry in active. Even more, should we support
to add
entry directly in 'active' or rather only support 'user-add' to
go only

in staging ?

I do not see why this would ever be necessary, ipa user-add cannot
create a corrupt entry by definition.

entry.

Simo.
/me wishes that the major concerns were spelled out during initial
RFE review...

Could this help a custom provisioning system that uses FreeIPA
user-add
JSON-RPC command instead of ldapadd? The record may still be
incomplete in
terms of company policy (e.g. missing manager) and about to be
moved only when

the user joins the company?

Or is this nonsense and we should avoid doing
user-add/user-mod/user-del in the

staging area?

Note that I did not say we should not have an IPA command for that, but
I dislike the idea of putting it in the user plugin and using that
specific command expression.

I would see something

Re: [Freeipa-devel] User life cycle: question regarding the design


On 05/23/2014 01:01 PM, Simo Sorce wrote:

On Fri, 2014-05-23 at 17:47 +0200, thierry bordaz wrote:

About membership. I think it could be risky to keep membership in
'delete' or 'stage'. Those entries are not valid user and should not
belong to any active group. Should we keep membership attributes in
those state or let the plugin recompute the valid values when the
entry
is back to active ?


Recompute.
When a user is deleted it loses the memberships, when it is reactivated
then new memberships need to be computed or explicitly added.

Simo.


Yes. This was a part of the initial design.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust

On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote:
 On 05/27/2014 03:52 PM, Simo Sorce wrote:
  On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote:
  On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote:
  Hi,
 
  I have started to write a design page for 'Migrating existing
  environments to Trust'
  http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust
  It shall cover https://fedorahosted.org/freeipa/ticket/3318 and
  https://fedorahosted.org/freeipa/ticket/3979 .
 
  while working on a new version of the page with more details on design
  and implementation I came across the following problem. On the IPA
  server there should be a way for SSSD to deliver unmodified data (no
  view applied) or views other than the one for the IPA server to
  processes which delivers user and group data to other clients. This are
  mainly the extdom and the compat plugin of dirsrv.
 
  The two currently use standard glibc calls like getpwnam_r() to get the
  needed data from SSSD. While they can read the view objects form the
  LDAP tree there is no way to read the original data for users from
  trusted domains because it is only in the cache of SSSD.
 
  I'm looking for a way to allow SSSD to deliver the data without changing
  the protocol used by the NSS responder.
 
  One way I can think of is to use a new socket like
  /var/lib/sss/pipes/nss_noview and create a small library for the extdom
  and compat plugin to use the new socket. With this the plugin have to
  apply the views on their own if needed.
 
  Another way would be a new command for the NSS responder with two
  arguments, the view name (or empty for unmodified data) and a blob which
  contains the data for the corresponding request like e.g. getpwnam_r() or
  getgrgid_r(). Here the plugins have to use some new calls but all view
  processing can happen in sssd and the plugins can deliver the data
  directly.
 
  A drawback in both cases is that the memcache cannot be used.
 
  If someone has suggestions for SSSD or other ways how to deliver user
  and group data to client with other views than the IPA server I'm all
  ears.
  Ok this one is hard to deal with in a way that will satisfy every
  possible user.
 
  I think what we need to aim is simplicity and predictability at the
  expense of flexibility.
 
  What I mean is that freeipa servers should be allowed to only stick to
  one view, the default view for external users.
 
 I do not understand what you mean by one view?

The one view is the view exposed via the (default) compat tree.

 Server should be able to have all views.
 View is an equivalent of the zones.
 
 SSSD has to get raw data from the external domain and give it to IPA.
 IPA would have to merge the data coming from SSSD in server mode with 
 some set of data associated with a subset of clients.
 I am not sure how it will be done (compat, cos or some other mechanism) 
 but this is the requirement.

This would require multiple compat trees, one per view, it would be very
expensive.

 So for clarity let me restate the use cases:
 
 a) I had my users in a NIS or LDAP with POSIX attributes there. I used 
 to sync users from AD. I migrate from that to IPA but want to use trust 
 for my users because AD is authoritative source and I do not want/can 
 put POSIX into AD.
 b) I have several NIS domains that I need to consolidate. For whatever 
 reasons I can't migrate to the unified POSIX namespace. I want an 
 equivalent of the Centrify Zones when different clients get different 
 uid/gid assignments for the same users.
 c) I used sync so my POSIX attributes are in IPA but now I want to 
 switch to trust.
 d) I had a third party solution that had posix zoning and I want to 
 replace it with the similar solution based on IPA.
 
 Views (plural) are a way to merge data and present it to a subset of 
 clients. In this context it is not really clear what you mean by one 
 view.

In order to see views you'll need a modern SSSD client that knows how to
apply them. Ie viewS are applied on the client side. The server shows
only one view via LDAP.

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: question regarding the design