subject:"\[Freeipa\-devel\] \[PATCHES 509\-514\] replica promotion\: use host credentials when setting up replication"

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-13 Thread Jan Cholasta


On 10.12.2015 15:01, Martin Babinsky wrote:

On 12/10/2015 07:57 AM, Jan Cholasta wrote:

On 9.12.2015 16:39, Jan Cholasta wrote:

On 7.12.2015 08:14, Jan Cholasta wrote:

On 6.12.2015 21:32, Martin Basti wrote:



On 04.12.2015 16:58, Simo Sorce wrote:

On Fri, 2015-12-04 at 15:39 +0100, Jan Cholasta wrote:

On 4.12.2015 15:16, Jan Cholasta wrote:

On 4.12.2015 15:12, Jan Cholasta wrote:

On 4.12.2015 11:15, Petr Vobornik wrote:

On 12/03/2015 03:11 PM, Martin Basti wrote:


On 01.12.2015 12:19, Jan Cholasta wrote:

On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:

Ad alternative is to add the host to ipaservers before the
checks
are
done and remove it again if any of them fail.

Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)

Updated patches attached. Note that 520 should be applied
between 509
and 510.




Functional ACK


Simo, do you want to review the ACIs or other things it the
patches? Or
can the patches be pushed?

There were no changes in the ACIs since last time.

Actually, memberPrincipal was removed from the "IPA server hosts
can
manage own Custodia secrets" ACI, as per Simo's request.


Rebased patches attached.

Note that 520 should still be applied between 509 and 510.


LGTM


ACK


Thanks.

Pushed to master: 01ddf51df76f3298499973355c5461727e46ab5b


Martin Babinsky found out that ipaservers is not created early enough
when installing a replica of a 4.2 or older server which causes a crash.

The attached patch fixes that.


Actually I don't like how I fixed that, here's an updated patch.

Also, I noticed that replica promotion fails too late in domain level 0.
Fixed as well.





ACK to both patches.


Thanks.

Pushed to master: b4a78db4e7d06237a715f088d1b914b47eccf32f

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-10 Thread Martin Babinsky


On 12/10/2015 07:57 AM, Jan Cholasta wrote:

On 9.12.2015 16:39, Jan Cholasta wrote:

On 7.12.2015 08:14, Jan Cholasta wrote:

On 6.12.2015 21:32, Martin Basti wrote:



On 04.12.2015 16:58, Simo Sorce wrote:

On Fri, 2015-12-04 at 15:39 +0100, Jan Cholasta wrote:

On 4.12.2015 15:16, Jan Cholasta wrote:

On 4.12.2015 15:12, Jan Cholasta wrote:

On 4.12.2015 11:15, Petr Vobornik wrote:

On 12/03/2015 03:11 PM, Martin Basti wrote:


On 01.12.2015 12:19, Jan Cholasta wrote:

On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:

Ad alternative is to add the host to ipaservers before the
checks
are
done and remove it again if any of them fail.

Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)

Updated patches attached. Note that 520 should be applied
between 509
and 510.




Functional ACK


Simo, do you want to review the ACIs or other things it the
patches? Or
can the patches be pushed?

There were no changes in the ACIs since last time.

Actually, memberPrincipal was removed from the "IPA server hosts can
manage own Custodia secrets" ACI, as per Simo's request.


Rebased patches attached.

Note that 520 should still be applied between 509 and 510.


LGTM


ACK


Thanks.

Pushed to master: 01ddf51df76f3298499973355c5461727e46ab5b


Martin Babinsky found out that ipaservers is not created early enough
when installing a replica of a 4.2 or older server which causes a crash.

The attached patch fixes that.


Actually I don't like how I fixed that, here's an updated patch.

Also, I noticed that replica promotion fails too late in domain level 0.
Fixed as well.





ACK to both patches.

--
Martin^3 Babinsky

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-09 Thread Jan Cholasta


On 7.12.2015 08:14, Jan Cholasta wrote:

On 6.12.2015 21:32, Martin Basti wrote:



On 04.12.2015 16:58, Simo Sorce wrote:

On Fri, 2015-12-04 at 15:39 +0100, Jan Cholasta wrote:

On 4.12.2015 15:16, Jan Cholasta wrote:

On 4.12.2015 15:12, Jan Cholasta wrote:

On 4.12.2015 11:15, Petr Vobornik wrote:

On 12/03/2015 03:11 PM, Martin Basti wrote:


On 01.12.2015 12:19, Jan Cholasta wrote:

On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:

Ad alternative is to add the host to ipaservers before the
checks
are
done and remove it again if any of them fail.

Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)

Updated patches attached. Note that 520 should be applied
between 509
and 510.




Functional ACK


Simo, do you want to review the ACIs or other things it the
patches? Or
can the patches be pushed?

There were no changes in the ACIs since last time.

Actually, memberPrincipal was removed from the "IPA server hosts can
manage own Custodia secrets" ACI, as per Simo's request.


Rebased patches attached.

Note that 520 should still be applied between 509 and 510.


LGTM


ACK


Thanks.

Pushed to master: 01ddf51df76f3298499973355c5461727e46ab5b


Martin Babinsky found out that ipaservers is not created early enough 
when installing a replica of a 4.2 or older server which causes a crash.


The attached patch fixes that.

--
Jan Cholasta
From eb887cf4291857b5fb5ce1bd991d460e7df4990b Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Wed, 9 Dec 2015 15:56:24 +0100
Subject: [PATCH] replica install: add ipaservers before the server's host
 entry is created

This prevents crash when adding the host entry to ipaservers when
installing replica of a 4.2 or older server.

https://fedorahosted.org/freeipa/ticket/3416
---
 ipaserver/install/dsinstance.py  | 4 
 ipaserver/install/krbinstance.py | 5 -
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index a58b0f7..1b82e56 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -417,6 +417,10 @@ class DsInstance(service.Service):
r_bindpw=self.dm_password)
 self.run_init_memberof = repl.needs_memberof_fixup()
 
+ld = ldapupdate.LDAPUpdate(ldapi=True)
+ld.update([os.path.join(paths.UPDATES_DIR,
+'20-ipaservers_hostgroup.update')])
+
 # Now that the server is up make sure all changes happen against
 # the local server (as repica pomotion does not have the DM password.
 if self.admin_conn:
diff --git a/ipaserver/install/krbinstance.py b/ipaserver/install/krbinstance.py
index f928e50..1a7b65a 100644
--- a/ipaserver/install/krbinstance.py
+++ b/ipaserver/install/krbinstance.py
@@ -122,7 +122,10 @@ class KrbInstance(service.Service):
   ('cn', 'accounts'), self.suffix)
 hostgroup_entry = self.admin_conn.get_entry(hostgroup_dn, ['member'])
 hostgroup_entry.setdefault('member', []).append(host_dn)
-self.admin_conn.update_entry(hostgroup_entry)
+try:
+self.admin_conn.update_entry(hostgroup_entry)
+except errors.EmptyModlist:
+pass
 
 def __common_setup(self, realm_name, host_name, domain_name, admin_password):
 self.fqdn = host_name
-- 
2.4.3

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-09 Thread Jan Cholasta


On 9.12.2015 16:39, Jan Cholasta wrote:

On 7.12.2015 08:14, Jan Cholasta wrote:

On 6.12.2015 21:32, Martin Basti wrote:



On 04.12.2015 16:58, Simo Sorce wrote:

On Fri, 2015-12-04 at 15:39 +0100, Jan Cholasta wrote:

On 4.12.2015 15:16, Jan Cholasta wrote:

On 4.12.2015 15:12, Jan Cholasta wrote:

On 4.12.2015 11:15, Petr Vobornik wrote:

On 12/03/2015 03:11 PM, Martin Basti wrote:


On 01.12.2015 12:19, Jan Cholasta wrote:

On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:

Ad alternative is to add the host to ipaservers before the
checks
are
done and remove it again if any of them fail.

Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)

Updated patches attached. Note that 520 should be applied
between 509
and 510.




Functional ACK


Simo, do you want to review the ACIs or other things it the
patches? Or
can the patches be pushed?

There were no changes in the ACIs since last time.

Actually, memberPrincipal was removed from the "IPA server hosts can
manage own Custodia secrets" ACI, as per Simo's request.


Rebased patches attached.

Note that 520 should still be applied between 509 and 510.


LGTM


ACK


Thanks.

Pushed to master: 01ddf51df76f3298499973355c5461727e46ab5b


Martin Babinsky found out that ipaservers is not created early enough
when installing a replica of a 4.2 or older server which causes a crash.

The attached patch fixes that.


Actually I don't like how I fixed that, here's an updated patch.

Also, I noticed that replica promotion fails too late in domain level 0. 
Fixed as well.


--
Jan Cholasta
From 00db51a7a3c3b38fc8e2680bbb0304d74ebabcfa Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Wed, 9 Dec 2015 15:56:24 +0100
Subject: [PATCH] replica install: add ipaservers if it does not exist

This prevents crash when adding the host entry to ipaservers when
installing replica of a 4.2 or older server.

https://fedorahosted.org/freeipa/ticket/3416
---
 ipaserver/install/krbinstance.py | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/ipaserver/install/krbinstance.py b/ipaserver/install/krbinstance.py
index f928e50..cd803b0 100644
--- a/ipaserver/install/krbinstance.py
+++ b/ipaserver/install/krbinstance.py
@@ -41,6 +41,7 @@ from ipapython.dn import DN
 
 from ipaserver.install import replication
 from ipaserver.install import dsinstance
+from ipaserver.install import ldapupdate
 
 import pyasn1.codec.ber.decoder
 import struct
@@ -118,11 +119,9 @@ class KrbInstance(service.Service):
 self.admin_conn.add_entry(host_entry)
 
 # Add the host to the ipaserver host group
-hostgroup_dn = DN(('cn', 'ipaservers'), ('cn', 'hostgroups'),
-  ('cn', 'accounts'), self.suffix)
-hostgroup_entry = self.admin_conn.get_entry(hostgroup_dn, ['member'])
-hostgroup_entry.setdefault('member', []).append(host_dn)
-self.admin_conn.update_entry(hostgroup_entry)
+ld = ldapupdate.LDAPUpdate(ldapi=True)
+ld.update([os.path.join(paths.UPDATES_DIR,
+'20-ipaservers_hostgroup.update')])
 
 def __common_setup(self, realm_name, host_name, domain_name, admin_password):
 self.fqdn = host_name
-- 
2.4.3

From cba6aa7404fb9475f34d189f7ed97ca63c7a2c0e Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Thu, 10 Dec 2015 07:23:18 +0100
Subject: [PATCH] replica promotion: check domain level before ipaservers
 membership

Check domain level before checking ipaservers membership to prevent
"not found" error when attempting replica promotion in domain level 0.

https://fedorahosted.org/freeipa/ticket/5401
---
 ipaserver/install/server/replicainstall.py | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py
index a42ed7e..d10dfd3 100644
--- a/ipaserver/install/server/replicainstall.py
+++ b/ipaserver/install/server/replicainstall.py
@@ -973,6 +973,20 @@ def promote_check(installer):
 replman = ReplicationManager(config.realm_name,
  config.master_host_name, None)
 
+# Detect the current domain level
+try:
+current = remote_api.Command['domainlevel_get']()['result']
+except errors.NotFound:
+# If we're joining an older master, domain entry is not
+# available
+current = constants.DOMAIN_LEVEL_0
+
+if current == constants.DOMAIN_LEVEL_0:
+raise RuntimeError(
+"You must provide a file generated by ipa-replica-prepare to "
+"create a replica when the domain is at level 0."
+)
+
 # Check authorization
 result = remote_api.Command['hostgroup_find'](
 cn=u'ipaservers',
@@ -1027,20 +1041,6 @@ def

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-06 Thread Martin Basti




On 04.12.2015 16:58, Simo Sorce wrote:

On Fri, 2015-12-04 at 15:39 +0100, Jan Cholasta wrote:

On 4.12.2015 15:16, Jan Cholasta wrote:

On 4.12.2015 15:12, Jan Cholasta wrote:

On 4.12.2015 11:15, Petr Vobornik wrote:

On 12/03/2015 03:11 PM, Martin Basti wrote:


On 01.12.2015 12:19, Jan Cholasta wrote:

On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:

Ad alternative is to add the host to ipaservers before the checks
are
done and remove it again if any of them fail.

Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)

Updated patches attached. Note that 520 should be applied between 509
and 510.




Functional ACK


Simo, do you want to review the ACIs or other things it the patches? Or
can the patches be pushed?

There were no changes in the ACIs since last time.

Actually, memberPrincipal was removed from the "IPA server hosts can
manage own Custodia secrets" ACI, as per Simo's request.


Rebased patches attached.

Note that 520 should still be applied between 509 and 510.


LGTM


ACK

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-06 Thread Jan Cholasta


On 6.12.2015 21:32, Martin Basti wrote:



On 04.12.2015 16:58, Simo Sorce wrote:

On Fri, 2015-12-04 at 15:39 +0100, Jan Cholasta wrote:

On 4.12.2015 15:16, Jan Cholasta wrote:

On 4.12.2015 15:12, Jan Cholasta wrote:

On 4.12.2015 11:15, Petr Vobornik wrote:

On 12/03/2015 03:11 PM, Martin Basti wrote:


On 01.12.2015 12:19, Jan Cholasta wrote:

On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:

Ad alternative is to add the host to ipaservers before the checks
are
done and remove it again if any of them fail.

Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)

Updated patches attached. Note that 520 should be applied
between 509
and 510.




Functional ACK


Simo, do you want to review the ACIs or other things it the
patches? Or
can the patches be pushed?

There were no changes in the ACIs since last time.

Actually, memberPrincipal was removed from the "IPA server hosts can
manage own Custodia secrets" ACI, as per Simo's request.


Rebased patches attached.

Note that 520 should still be applied between 509 and 510.


LGTM


ACK


Thanks.

Pushed to master: 01ddf51df76f3298499973355c5461727e46ab5b

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-04 Thread Petr Vobornik


On 12/03/2015 03:11 PM, Martin Basti wrote:



On 01.12.2015 12:19, Jan Cholasta wrote:

On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:


Ad alternative is to add the host to ipaservers before the checks are
done and remove it again if any of them fail.


Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)


Updated patches attached. Note that 520 should be applied between 509
and 510.




Functional ACK



Simo, do you want to review the ACIs or other things it the patches? Or 
can the patches be pushed?

--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-04 Thread Simo Sorce

On Fri, 2015-12-04 at 15:39 +0100, Jan Cholasta wrote:
> On 4.12.2015 15:16, Jan Cholasta wrote:
> > On 4.12.2015 15:12, Jan Cholasta wrote:
> >> On 4.12.2015 11:15, Petr Vobornik wrote:
> >>> On 12/03/2015 03:11 PM, Martin Basti wrote:
> 
> 
>  On 01.12.2015 12:19, Jan Cholasta wrote:
> > On 23.11.2015 15:47, Simo Sorce wrote:
> >> On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:
> >>>
> >>> Ad alternative is to add the host to ipaservers before the checks
> >>> are
> >>> done and remove it again if any of them fail.
> >>
> >> Too error prone, I am ok with the current way in your patches
> >> until/unless I can think of a fail safe way. :-)
> >
> > Updated patches attached. Note that 520 should be applied between 509
> > and 510.
> >
> >
> >
>  Functional ACK
> 
> >>>
> >>> Simo, do you want to review the ACIs or other things it the patches? Or
> >>> can the patches be pushed?
> >>
> >> There were no changes in the ACIs since last time.
> >
> > Actually, memberPrincipal was removed from the "IPA server hosts can
> > manage own Custodia secrets" ACI, as per Simo's request.
> >
> >>
> >> Rebased patches attached.
> 
> Note that 520 should still be applied between 509 and 510.
> 

LGTM

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-04 Thread Jan Cholasta


On 4.12.2015 15:16, Jan Cholasta wrote:

On 4.12.2015 15:12, Jan Cholasta wrote:

On 4.12.2015 11:15, Petr Vobornik wrote:

On 12/03/2015 03:11 PM, Martin Basti wrote:



On 01.12.2015 12:19, Jan Cholasta wrote:

On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:


Ad alternative is to add the host to ipaservers before the checks
are
done and remove it again if any of them fail.


Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)


Updated patches attached. Note that 520 should be applied between 509
and 510.




Functional ACK



Simo, do you want to review the ACIs or other things it the patches? Or
can the patches be pushed?


There were no changes in the ACIs since last time.


Actually, memberPrincipal was removed from the "IPA server hosts can
manage own Custodia secrets" ACI, as per Simo's request.



Rebased patches attached.


Note that 520 should still be applied between 509 and 510.

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-04 Thread Jan Cholasta


On 4.12.2015 11:15, Petr Vobornik wrote:

On 12/03/2015 03:11 PM, Martin Basti wrote:



On 01.12.2015 12:19, Jan Cholasta wrote:

On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:


Ad alternative is to add the host to ipaservers before the checks are
done and remove it again if any of them fail.


Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)


Updated patches attached. Note that 520 should be applied between 509
and 510.




Functional ACK



Simo, do you want to review the ACIs or other things it the patches? Or
can the patches be pushed?


There were no changes in the ACIs since last time.

Rebased patches attached.

--
Jan Cholasta
From 0b7455460928df1376029e7b3b9d5c76308eb148 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Tue, 1 Dec 2015 10:42:38 +0100
Subject: [PATCH 1/2] aci: add IPA servers host group 'ipaservers'

https://fedorahosted.org/freeipa/ticket/3416
---
 ACI.txt|  4 ++--
 install/share/bootstrap-template.ldif  | 11 +++
 install/updates/20-ipaservers_hostgroup.update | 13 +
 install/updates/Makefile.am|  1 +
 ipalib/plugins/host.py |  6 ++
 ipalib/plugins/hostgroup.py| 26 ++
 ipaserver/install/krbinstance.py   |  7 +++
 7 files changed, 66 insertions(+), 2 deletions(-)
 create mode 100644 install/updates/20-ipaservers_hostgroup.update

diff --git a/ACI.txt b/ACI.txt
index 40fa822..bbc2e66 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -119,7 +119,7 @@ aci: (targetattr = "usercertificate")(targetfilter = "(objectclass=ipahost)")(ve
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = "userpassword")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Enrollment Password";allow (write) groupdn = "ldap:///cn=System: Manage Host Enrollment Password,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
-aci: (targetattr = "krblastpwdchange || krbprincipalkey")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab";allow (write) groupdn = "ldap:///cn=System: Manage Host Keytab,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetattr = "krblastpwdchange || krbprincipalkey")(targetfilter = "(&(!(memberOf=cn=ipaservers,cn=hostgroups,cn=accounts,dc=ipa,dc=example))(objectclass=ipahost))")(version 3.0;acl "permission:System: Manage Host Keytab";allow (write) groupdn = "ldap:///cn=System: Manage Host Keytab,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = "createtimestamp || entryusn || ipaallowedtoperform;read_keys || ipaallowedtoperform;write_keys || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab Permissions";allow (compare,read,search,write) groupdn = "ldap:///cn=System: Manage Host Keytab Permissions,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
@@ -137,7 +137,7 @@ aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System
 dn: cn=hostgroups,cn=accounts,dc=ipa,dc=example
 aci: (targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:System: Add Hostgroups";allow (add) groupdn = "ldap:///cn=System: Add Hostgroups,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hostgroups,cn=accounts,dc=ipa,dc=example
-aci: (targetattr = "member")(targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:System: Modify Hostgroup Membership";allow (write) groupdn = "ldap:///cn=System: Modify Hostgroup Membership,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetattr = "member")(targetfilter = "(&(!(cn=ipaservers))(objectclass=ipahostgroup))")(version 3.0;acl "permission:System: Modify Hostgroup Membership";allow (write) groupdn = "ldap:///cn=System: Modify Hostgroup Membership,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hostgroups,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = "cn || description")(targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:System: Modify Hostgroups";allow (write) groupdn = "ldap:///cn=System: Modify Hostgroups,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hostgroups,cn=accounts,dc=ipa,dc=example
diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif
index 3570627..628a8e2 100644
--- a/install/share/bootstrap-template.ldif
+++ b/install/share/bootstrap-template.ldif
@@ -261,6 +261,17 @@ description: Limited admins who can edit other users
 cn: editors
 ipaUniqueID: autogenerate
 
+dn: cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX
+changetype: add
+objectClass: top
+objectClass: groupOfNames
+objectClass: nestedGroup
+objectClass:

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-04 Thread Jan Cholasta


On 4.12.2015 15:12, Jan Cholasta wrote:

On 4.12.2015 11:15, Petr Vobornik wrote:

On 12/03/2015 03:11 PM, Martin Basti wrote:



On 01.12.2015 12:19, Jan Cholasta wrote:

On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:


Ad alternative is to add the host to ipaservers before the checks are
done and remove it again if any of them fail.


Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)


Updated patches attached. Note that 520 should be applied between 509
and 510.




Functional ACK



Simo, do you want to review the ACIs or other things it the patches? Or
can the patches be pushed?


There were no changes in the ACIs since last time.


Actually, memberPrincipal was removed from the "IPA server hosts can 
manage own Custodia secrets" ACI, as per Simo's request.




Rebased patches attached.



--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-03 Thread Martin Basti




On 01.12.2015 12:19, Jan Cholasta wrote:

On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:


Ad alternative is to add the host to ipaservers before the checks are
done and remove it again if any of them fail.


Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)


Updated patches attached. Note that 520 should be applied between 509 
and 510.





Functional ACK
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-12-01 Thread Jan Cholasta


On 23.11.2015 15:47, Simo Sorce wrote:

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:


Ad alternative is to add the host to ipaservers before the checks are
done and remove it again if any of them fail.


Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)


Updated patches attached. Note that 520 should be applied between 509 
and 510.


--
Jan Cholasta
From 3044955bb8358ca268c61dc19900dcfbc1a91fee Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Tue, 1 Dec 2015 10:42:38 +0100
Subject: [PATCH 1/2] aci: add IPA servers host group 'ipaservers'

https://fedorahosted.org/freeipa/ticket/3416
---
 ACI.txt|  4 ++--
 install/share/bootstrap-template.ldif  | 11 +++
 install/updates/20-ipaservers_hostgroup.update | 13 +
 install/updates/Makefile.am|  1 +
 ipalib/plugins/host.py |  6 ++
 ipalib/plugins/hostgroup.py| 26 ++
 ipaserver/install/krbinstance.py   |  7 +++
 7 files changed, 66 insertions(+), 2 deletions(-)
 create mode 100644 install/updates/20-ipaservers_hostgroup.update

diff --git a/ACI.txt b/ACI.txt
index 40fa822..bbc2e66 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -119,7 +119,7 @@ aci: (targetattr = "usercertificate")(targetfilter = "(objectclass=ipahost)")(ve
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = "userpassword")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Enrollment Password";allow (write) groupdn = "ldap:///cn=System: Manage Host Enrollment Password,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
-aci: (targetattr = "krblastpwdchange || krbprincipalkey")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab";allow (write) groupdn = "ldap:///cn=System: Manage Host Keytab,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetattr = "krblastpwdchange || krbprincipalkey")(targetfilter = "(&(!(memberOf=cn=ipaservers,cn=hostgroups,cn=accounts,dc=ipa,dc=example))(objectclass=ipahost))")(version 3.0;acl "permission:System: Manage Host Keytab";allow (write) groupdn = "ldap:///cn=System: Manage Host Keytab,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = "createtimestamp || entryusn || ipaallowedtoperform;read_keys || ipaallowedtoperform;write_keys || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab Permissions";allow (compare,read,search,write) groupdn = "ldap:///cn=System: Manage Host Keytab Permissions,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
@@ -137,7 +137,7 @@ aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System
 dn: cn=hostgroups,cn=accounts,dc=ipa,dc=example
 aci: (targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:System: Add Hostgroups";allow (add) groupdn = "ldap:///cn=System: Add Hostgroups,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hostgroups,cn=accounts,dc=ipa,dc=example
-aci: (targetattr = "member")(targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:System: Modify Hostgroup Membership";allow (write) groupdn = "ldap:///cn=System: Modify Hostgroup Membership,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetattr = "member")(targetfilter = "(&(!(cn=ipaservers))(objectclass=ipahostgroup))")(version 3.0;acl "permission:System: Modify Hostgroup Membership";allow (write) groupdn = "ldap:///cn=System: Modify Hostgroup Membership,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hostgroups,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = "cn || description")(targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:System: Modify Hostgroups";allow (write) groupdn = "ldap:///cn=System: Modify Hostgroups,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hostgroups,cn=accounts,dc=ipa,dc=example
diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif
index 3570627..628a8e2 100644
--- a/install/share/bootstrap-template.ldif
+++ b/install/share/bootstrap-template.ldif
@@ -261,6 +261,17 @@ description: Limited admins who can edit other users
 cn: editors
 ipaUniqueID: autogenerate
 
+dn: cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX
+changetype: add
+objectClass: top
+objectClass: groupOfNames
+objectClass: nestedGroup
+objectClass: ipaobject
+objectClass: ipahostgroup
+description: IPA server hosts
+cn: ipaservers
+ipaUniqueID: autogenerate
+
 dn: cn=sshd,cn=hbacservices,cn=hbac,$SUFFIX
 changetype: add
 objectclass: ipahbacservice
diff --git a/install/updates/20-ipaservers_hostgroup.update b/install/updates/20-ipaservers_hostgroup.update
new file mode 100644

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-30 Thread Simo Sorce

On Thu, 2015-11-26 at 07:47 +0100, Jan Cholasta wrote:
> On 25.11.2015 18:46, Simo Sorce wrote:
> > On Wed, 2015-11-25 at 10:25 +0100, Jan Cholasta wrote:
> >> On 20.11.2015 16:49, Jan Cholasta wrote:
> >>> On 19.11.2015 17:43, Simo Sorce wrote:
>  510:
>  - We should probably tightenup the ACI to allos host X to only add
>  memberPrincipal = X and no other value, also the host should not be
>  allowed to change the memberPrincipal attribute only the keys.
>  If we can't express this in ACIs we can live with the ones you propose
>  though.
> >>>
> >>> I think this can be done.
> >>
> >> Turns out this can be done only if member (or some other DN attribute)
> >> is used instead of memberPrincipal.
> >>
> >> So, to reiterate:
> >>
> > 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?
> >
> > If 'member' was used instead, we would gain referential integrity and
> > the ability to add ACIs based on the attribute (think
> > userattr="member#USERDN").
> 
>  To avoid referential integrity and mixup with other group objects, it
>  was intentional.
> >>
> >> Why is referential integrity a problem?
> >
> > Because it will remove the member if the object it references goes away,
> > and I do not want an "orphaned" entry for custodia.
> 
> But without referential integrity you get an orphaned entry too, except 
> with an extra dangling reference. IMHO that's even worse than "plain" 
> orhpaned entry, because you can't spot it just by looking at the 
> attribute value.
> 
> >
> >> Mixup with other group objects can be solved by using a different 
> >> attribute.
> >
> > There is also the fact in future we may want to use this with "external"
> > principals (like in IPA-IPA trusts or similar) so I didn't want to have
> > to come up with bogus DNs in that case.
> 
> IIRC Alexander was working on something like exposing external 
> principals in LDAP using the compat plugin, in order to allow external 
> users to run IPA commands.

We do not want to depend on the compat tree in such a core feature.

> Alternatively, it could do what groups do - use DN for internal 
> references and string (be it principal or something else) for external 
> references.

Same as above.

> Anyway, either memberPrincipal is replaced with a member-like attribute, 
> or the ACI stays as it is. I would prefer a member-like attribute, 
> because I feel that's the way LDAP entries should reference each other, 
> but I will leave the decision to you.

Let's keep it as it is for now, I'll think more about it.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-25 Thread Simo Sorce

On Wed, 2015-11-25 at 10:25 +0100, Jan Cholasta wrote:
> On 20.11.2015 16:49, Jan Cholasta wrote:
> > On 19.11.2015 17:43, Simo Sorce wrote:
> >> 510:
> >> - We should probably tightenup the ACI to allos host X to only add
> >> memberPrincipal = X and no other value, also the host should not be
> >> allowed to change the memberPrincipal attribute only the keys.
> >> If we can't express this in ACIs we can live with the ones you propose
> >> though.
> >
> > I think this can be done.
> 
> Turns out this can be done only if member (or some other DN attribute) 
> is used instead of memberPrincipal.
> 
> So, to reiterate:
> 
> >>> 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?
> >>>
> >>> If 'member' was used instead, we would gain referential integrity and
> >>> the ability to add ACIs based on the attribute (think
> >>> userattr="member#USERDN").
> >>
> >> To avoid referential integrity and mixup with other group objects, it
> >> was intentional.
> 
> Why is referential integrity a problem?

Because it will remove the member if the object it references goes away,
and I do not want an "orphaned" entry for custodia.

> Mixup with other group objects can be solved by using a different attribute.

There is also the fact in future we may want to use this with "external"
principals (like in IPA-IPA trusts or similar) so I didn't want to have
to come up with bogus DNs in that case.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-25 Thread Oleg Fayans


Hi,

Should I cover ticket N 3416 in the replica promotion test plan? It 
should be tested, and IMO there is no sense in creating a separate test 
plan for just that.


On 11/19/2015 03:43 PM, Jan Cholasta wrote:

Hi,

the attached patches fix 
and .

I worked around the issue of checking if the user is privileged to
perform replica promotion by using host credentials instead. The host
must be a member of the IPA servers host group "ipaservers" in order to
be able to promote itself. Using host credentials will also allow
replica install using one-time password.

User credentials are still used for connection check and to
automatically add the host to ipaservers if the user is privileged to do
that.

Simo, is this approach OK? Could you check the new ACIs in patches 510
and 513?

I have a couple of questions:

1) Why are custodia keys for the replica added to LDAP using connection
to the remote master instead of local ldapi connection? Is it to
eliminate race conditions caused by replication timeout from the replica
to the remote master?

If the code was changed to use ldapi and wait until the key appears in
custodia on the remote master, we could lose the "IPA server hosts can
create own Custodia secrets" and "IPA server hosts can manage own
Custodia secrets" ACIs from patch 510. Not sure if it's worth the change
though.

2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?

If 'member' was used instead, we would gain referential integrity and
the ability to add ACIs based on the attribute (think
userattr="member#USERDN").

3) Why is 'memberPrincipal' used in cn=custodia at all?

The hostname of the replica is already in 'cn', so instead of searching
cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we
could get cn={enc,sig}/$HOSTNAME,cn=custodia directly.

Honza





--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-25 Thread Jan Cholasta


Works for me.

On 25.11.2015 21:35, Oleg Fayans wrote:

Hi,

Should I cover ticket N 3416 in the replica promotion test plan? It
should be tested, and IMO there is no sense in creating a separate test
plan for just that.

On 11/19/2015 03:43 PM, Jan Cholasta wrote:

Hi,

the attached patches fix 
and .

I worked around the issue of checking if the user is privileged to
perform replica promotion by using host credentials instead. The host
must be a member of the IPA servers host group "ipaservers" in order to
be able to promote itself. Using host credentials will also allow
replica install using one-time password.

User credentials are still used for connection check and to
automatically add the host to ipaservers if the user is privileged to do
that.

Simo, is this approach OK? Could you check the new ACIs in patches 510
and 513?

I have a couple of questions:

1) Why are custodia keys for the replica added to LDAP using connection
to the remote master instead of local ldapi connection? Is it to
eliminate race conditions caused by replication timeout from the replica
to the remote master?

If the code was changed to use ldapi and wait until the key appears in
custodia on the remote master, we could lose the "IPA server hosts can
create own Custodia secrets" and "IPA server hosts can manage own
Custodia secrets" ACIs from patch 510. Not sure if it's worth the change
though.

2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?

If 'member' was used instead, we would gain referential integrity and
the ability to add ACIs based on the attribute (think
userattr="member#USERDN").

3) Why is 'memberPrincipal' used in cn=custodia at all?

The hostname of the replica is already in 'cn', so instead of searching
cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we
could get cn={enc,sig}/$HOSTNAME,cn=custodia directly.

Honza








--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-25 Thread Jan Cholasta


On 25.11.2015 18:46, Simo Sorce wrote:

On Wed, 2015-11-25 at 10:25 +0100, Jan Cholasta wrote:

On 20.11.2015 16:49, Jan Cholasta wrote:

On 19.11.2015 17:43, Simo Sorce wrote:

510:
- We should probably tightenup the ACI to allos host X to only add
memberPrincipal = X and no other value, also the host should not be
allowed to change the memberPrincipal attribute only the keys.
If we can't express this in ACIs we can live with the ones you propose
though.


I think this can be done.


Turns out this can be done only if member (or some other DN attribute)
is used instead of memberPrincipal.

So, to reiterate:


2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?

If 'member' was used instead, we would gain referential integrity and
the ability to add ACIs based on the attribute (think
userattr="member#USERDN").


To avoid referential integrity and mixup with other group objects, it
was intentional.


Why is referential integrity a problem?


Because it will remove the member if the object it references goes away,
and I do not want an "orphaned" entry for custodia.


But without referential integrity you get an orphaned entry too, except 
with an extra dangling reference. IMHO that's even worse than "plain" 
orhpaned entry, because you can't spot it just by looking at the 
attribute value.





Mixup with other group objects can be solved by using a different attribute.


There is also the fact in future we may want to use this with "external"
principals (like in IPA-IPA trusts or similar) so I didn't want to have
to come up with bogus DNs in that case.


IIRC Alexander was working on something like exposing external 
principals in LDAP using the compat plugin, in order to allow external 
users to run IPA commands.


Alternatively, it could do what groups do - use DN for internal 
references and string (be it principal or something else) for external 
references.


Anyway, either memberPrincipal is replaced with a member-like attribute, 
or the ACI stays as it is. I would prefer a member-like attribute, 
because I feel that's the way LDAP entries should reference each other, 
but I will leave the decision to you.


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-25 Thread Jan Cholasta


On 20.11.2015 16:49, Jan Cholasta wrote:

On 19.11.2015 17:43, Simo Sorce wrote:

510:
- We should probably tightenup the ACI to allos host X to only add
memberPrincipal = X and no other value, also the host should not be
allowed to change the memberPrincipal attribute only the keys.
If we can't express this in ACIs we can live with the ones you propose
though.


I think this can be done.


Turns out this can be done only if member (or some other DN attribute) 
is used instead of memberPrincipal.


So, to reiterate:


2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?

If 'member' was used instead, we would gain referential integrity and
the ability to add ACIs based on the attribute (think
userattr="member#USERDN").


To avoid referential integrity and mixup with other group objects, it
was intentional.


Why is referential integrity a problem?

Mixup with other group objects can be solved by using a different attribute.

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-23 Thread Jan Cholasta


On 23.11.2015 15:34, Simo Sorce wrote:

On Mon, 2015-11-23 at 08:54 +0100, Jan Cholasta wrote:

On 20.11.2015 17:58, Simo Sorce wrote:

On Fri, 2015-11-20 at 16:49 +0100, Jan Cholasta wrote:

On 19.11.2015 17:43, Simo Sorce wrote:

[..]

On the patches
--
509:
- commit says only: "aci: add IPA servers host group 'ipaservers'"
but it does other things like changing how CA renewal certificate acis
are added, I think that must be separated in another patch.

- Why "Manage Host Keytab"  aci has been changed to exclude ipaservers ?


To allow only members of the admins group to manage keytabs of IPA
servers. This is analogous to how only members of the admins group can
change passwords of other admins.


I guess there is an interaction between ACIs I am not getting here, can
you give a small overview of how we end up here ?


This ACI allows admins to modify keytab of any host:

aci: (targetattr = "krbPrincipalKey || krbLastPwdChange")(target =
"ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX;)(version 3.0;acl
"Admins can manage host keytab";allow (write) groupdn =
"ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;)

The original "Manage Host Keytab" ACI allows any user with the
corresponding permission to modify keytab of any host.

The modified "Manage Host Keytab" ACI allows any user with the
correcponding permission to modify keytab of any host except for members
of ipaservers.

The result is that the user has to be member of admins to be able to
modify keytab of IPA servers.


If IPAservers are not supposed to access those attributes, why are they
added to the permissions at all ?


The effect of the change is not to limit access of IPA servers, but to
limit access of non-admin users *to* IPA servers.


Ah, thanks for explaining, this makes a lot of sense.


Wouldn't it make sense to have 2 set of permissions ?
One for admin type users (with access to all attributes) and one for
less privileged users ?


There already is a separate ACI which allows admins full access to the
attributes, see above.




- Why adding the host to the ipaservers group is done in the
krbinstance ? I would expect LDAP ops to be mostly done in the
DSinstance.


It is the same place where the host entry is created.


I will translate this with "historical" :-)


- I do not see where the host is added to the ipaservers group on
upgrade.


It's in install/updates/20-ipaservers_hostgroup.update:

add: member: fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX


Ahh, I missed that, thanks!


510:
- We should probably tightenup the ACI to allos host X to only add
memberPrincipal = X and no other value, also the host should not be
allowed to change the memberPrincipal attribute only the keys.
If we can't express this in ACIs we can live with the ones you propose
though.


I think this can be done.

memberPrincipal is included in the ACI because KEMLdap.set_key() touches
it. Perhaps it is not intentional?


Yeah, it is a bug in set_key(), of course we need to add memberPrincipal
when creating a whole new entry, but we should not modify it on existing
entries.


I though so, I will fix that.




511:
ack, but I think you should catch potential exceptions from the
os.rmdir, as it will throw if there is some other file in the dir (for
whatever reason). The exception can be safely ignored, we just do not
want to blow up with a traceback here.


OK.



512:
- I do not think this is correct, it seem to me you are overriding the
local ccache (if any) with the host keytab. If I read this right, this
means that if you run kinit admin && ipa-replica-install then you will
kind your admin credentials gone and a host TGT instead. Am I reading
this change correctly ?


No. :-) Temporary ccache is now used for the install and the host is
kinited into it. The initial ccache is used only for connection check
(and adding the host to ipaservers in patch 514). Your kinit admin will
not be lost.


Ok, got it.



513:
Nack
- Should be folded into 510


These ACIs are required only for patch 514.


Yes, but they are close and will give a full picture of the change
required for the feature if they are together. They won't hurt anything
even if unused until a few patches later (IIUC).


OK, makes sense.




- Should not allow all hosts in the domain but only ipaservers for aal
three changes


If the host isn't member of ipaservers before ipa-replica-install is
run, the "Check that we don't already have a replication agreement",
"Detect if the other master can handle replication managers" and "Find
if any server has a CA" steps will fail without these ACIs, which breaks
patch 514.


Yes I understood that, but it is intentional, these are administrative
checks, they need to be done as admin or with a host account that has
been pre-added to the ipaservers group. We do not want to expose
information to all other hosts in the domain as replication agreements
can include passwords in some cases, or other access information the
admin may not want to make available to random

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-23 Thread Simo Sorce

On Mon, 2015-11-23 at 08:54 +0100, Jan Cholasta wrote:
> On 20.11.2015 17:58, Simo Sorce wrote:
> > On Fri, 2015-11-20 at 16:49 +0100, Jan Cholasta wrote:
> >> On 19.11.2015 17:43, Simo Sorce wrote:
> > [..]
> >>> On the patches
> >>> --
> >>> 509:
> >>> - commit says only: "aci: add IPA servers host group 'ipaservers'"
> >>> but it does other things like changing how CA renewal certificate acis
> >>> are added, I think that must be separated in another patch.
> >>>
> >>> - Why "Manage Host Keytab"  aci has been changed to exclude ipaservers ?
> >>
> >> To allow only members of the admins group to manage keytabs of IPA
> >> servers. This is analogous to how only members of the admins group can
> >> change passwords of other admins.
> >
> > I guess there is an interaction between ACIs I am not getting here, can
> > you give a small overview of how we end up here ?
> 
> This ACI allows admins to modify keytab of any host:
> 
> aci: (targetattr = "krbPrincipalKey || krbLastPwdChange")(target = 
> "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX;)(version 3.0;acl 
> "Admins can manage host keytab";allow (write) groupdn = 
> "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;)
> 
> The original "Manage Host Keytab" ACI allows any user with the 
> corresponding permission to modify keytab of any host.
> 
> The modified "Manage Host Keytab" ACI allows any user with the 
> correcponding permission to modify keytab of any host except for members 
> of ipaservers.
> 
> The result is that the user has to be member of admins to be able to 
> modify keytab of IPA servers.
> 
> > If IPAservers are not supposed to access those attributes, why are they
> > added to the permissions at all ?
> 
> The effect of the change is not to limit access of IPA servers, but to 
> limit access of non-admin users *to* IPA servers.

Ah, thanks for explaining, this makes a lot of sense.

> > Wouldn't it make sense to have 2 set of permissions ?
> > One for admin type users (with access to all attributes) and one for
> > less privileged users ?
> 
> There already is a separate ACI which allows admins full access to the 
> attributes, see above.
> 
> >
> >>> - Why adding the host to the ipaservers group is done in the
> >>> krbinstance ? I would expect LDAP ops to be mostly done in the
> >>> DSinstance.
> >>
> >> It is the same place where the host entry is created.
> >
> > I will translate this with "historical" :-)
> >
> >>> - I do not see where the host is added to the ipaservers group on
> >>> upgrade.
> >>
> >> It's in install/updates/20-ipaservers_hostgroup.update:
> >>
> >> add: member: fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX
> >
> > Ahh, I missed that, thanks!
> >
> >>> 510:
> >>> - We should probably tightenup the ACI to allos host X to only add
> >>> memberPrincipal = X and no other value, also the host should not be
> >>> allowed to change the memberPrincipal attribute only the keys.
> >>> If we can't express this in ACIs we can live with the ones you propose
> >>> though.
> >>
> >> I think this can be done.
> >>
> >> memberPrincipal is included in the ACI because KEMLdap.set_key() touches
> >> it. Perhaps it is not intentional?
> >
> > Yeah, it is a bug in set_key(), of course we need to add memberPrincipal
> > when creating a whole new entry, but we should not modify it on existing
> > entries.
> 
> I though so, I will fix that.
> 
> >
> >>> 511:
> >>> ack, but I think you should catch potential exceptions from the
> >>> os.rmdir, as it will throw if there is some other file in the dir (for
> >>> whatever reason). The exception can be safely ignored, we just do not
> >>> want to blow up with a traceback here.
> >>
> >> OK.
> >>
> >>>
> >>> 512:
> >>> - I do not think this is correct, it seem to me you are overriding the
> >>> local ccache (if any) with the host keytab. If I read this right, this
> >>> means that if you run kinit admin && ipa-replica-install then you will
> >>> kind your admin credentials gone and a host TGT instead. Am I reading
> >>> this change correctly ?
> >>
> >> No. :-) Temporary ccache is now used for the install and the host is
> >> kinited into it. The initial ccache is used only for connection check
> >> (and adding the host to ipaservers in patch 514). Your kinit admin will
> >> not be lost.
> >
> > Ok, got it.
> >
> >>>
> >>> 513:
> >>> Nack
> >>> - Should be folded into 510
> >>
> >> These ACIs are required only for patch 514.
> >
> > Yes, but they are close and will give a full picture of the change
> > required for the feature if they are together. They won't hurt anything
> > even if unused until a few patches later (IIUC).
> 
> OK, makes sense.
> 
> >
> >>> - Should not allow all hosts in the domain but only ipaservers for aal
> >>> three changes
> >>
> >> If the host isn't member of ipaservers before ipa-replica-install is
> >> run, the "Check that we don't already have a replication agreement",
> >> "Detect if the other master can handle replication managers" and "Find
> >> if any server

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-23 Thread Simo Sorce

On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote:
> 
> Ad alternative is to add the host to ipaservers before the checks are 
> done and remove it again if any of them fail.

Too error prone, I am ok with the current way in your patches
until/unless I can think of a fail safe way. :-)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-22 Thread Jan Cholasta


On 20.11.2015 17:58, Simo Sorce wrote:

On Fri, 2015-11-20 at 16:49 +0100, Jan Cholasta wrote:

On 19.11.2015 17:43, Simo Sorce wrote:

[..]

On the patches
--
509:
- commit says only: "aci: add IPA servers host group 'ipaservers'"
but it does other things like changing how CA renewal certificate acis
are added, I think that must be separated in another patch.

- Why "Manage Host Keytab"  aci has been changed to exclude ipaservers ?


To allow only members of the admins group to manage keytabs of IPA
servers. This is analogous to how only members of the admins group can
change passwords of other admins.


I guess there is an interaction between ACIs I am not getting here, can
you give a small overview of how we end up here ?


This ACI allows admins to modify keytab of any host:

aci: (targetattr = "krbPrincipalKey || krbLastPwdChange")(target = 
"ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX;)(version 3.0;acl 
"Admins can manage host keytab";allow (write) groupdn = 
"ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;)


The original "Manage Host Keytab" ACI allows any user with the 
corresponding permission to modify keytab of any host.


The modified "Manage Host Keytab" ACI allows any user with the 
correcponding permission to modify keytab of any host except for members 
of ipaservers.


The result is that the user has to be member of admins to be able to 
modify keytab of IPA servers.



If IPAservers are not supposed to access those attributes, why are they
added to the permissions at all ?


The effect of the change is not to limit access of IPA servers, but to 
limit access of non-admin users *to* IPA servers.



Wouldn't it make sense to have 2 set of permissions ?
One for admin type users (with access to all attributes) and one for
less privileged users ?


There already is a separate ACI which allows admins full access to the 
attributes, see above.





- Why adding the host to the ipaservers group is done in the
krbinstance ? I would expect LDAP ops to be mostly done in the
DSinstance.


It is the same place where the host entry is created.


I will translate this with "historical" :-)


- I do not see where the host is added to the ipaservers group on
upgrade.


It's in install/updates/20-ipaservers_hostgroup.update:

add: member: fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX


Ahh, I missed that, thanks!


510:
- We should probably tightenup the ACI to allos host X to only add
memberPrincipal = X and no other value, also the host should not be
allowed to change the memberPrincipal attribute only the keys.
If we can't express this in ACIs we can live with the ones you propose
though.


I think this can be done.

memberPrincipal is included in the ACI because KEMLdap.set_key() touches
it. Perhaps it is not intentional?


Yeah, it is a bug in set_key(), of course we need to add memberPrincipal
when creating a whole new entry, but we should not modify it on existing
entries.


I though so, I will fix that.




511:
ack, but I think you should catch potential exceptions from the
os.rmdir, as it will throw if there is some other file in the dir (for
whatever reason). The exception can be safely ignored, we just do not
want to blow up with a traceback here.


OK.



512:
- I do not think this is correct, it seem to me you are overriding the
local ccache (if any) with the host keytab. If I read this right, this
means that if you run kinit admin && ipa-replica-install then you will
kind your admin credentials gone and a host TGT instead. Am I reading
this change correctly ?


No. :-) Temporary ccache is now used for the install and the host is
kinited into it. The initial ccache is used only for connection check
(and adding the host to ipaservers in patch 514). Your kinit admin will
not be lost.


Ok, got it.



513:
Nack
- Should be folded into 510


These ACIs are required only for patch 514.


Yes, but they are close and will give a full picture of the change
required for the feature if they are together. They won't hurt anything
even if unused until a few patches later (IIUC).


OK, makes sense.




- Should not allow all hosts in the domain but only ipaservers for aal
three changes


If the host isn't member of ipaservers before ipa-replica-install is
run, the "Check that we don't already have a replication agreement",
"Detect if the other master can handle replication managers" and "Find
if any server has a CA" steps will fail without these ACIs, which breaks
patch 514.


Yes I understood that, but it is intentional, these are administrative
checks, they need to be done as admin or with a host account that has
been pre-added to the ipaservers group. We do not want to expose
information to all other hosts in the domain as replication agreements
can include passwords in some cases, or other access information the
admin may not want to make available to random hosts.


The access is limited to objectclass and cn only, so the hosts will be 
able to see only if the entry exists.


Additionaly, for

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-20 Thread Jan Cholasta


On 19.11.2015 17:43, Simo Sorce wrote:

On Thu, 2015-11-19 at 15:43 +0100, Jan Cholasta wrote:

Hi,

the attached patches fix 
and .

I worked around the issue of checking if the user is privileged to
perform replica promotion by using host credentials instead. The host
must be a member of the IPA servers host group "ipaservers" in order to
be able to promote itself. Using host credentials will also allow
replica install using one-time password.

User credentials are still used for connection check and to
automatically add the host to ipaservers if the user is privileged to do
that.

Simo, is this approach OK? Could you check the new ACIs in patches 510
and 513?

I have a couple of questions:

1) Why are custodia keys for the replica added to LDAP using connection
to the remote master instead of local ldapi connection? Is it to
eliminate race conditions caused by replication timeout from the replica
to the remote master?


Yes it is critical for that reason.


If the code was changed to use ldapi and wait until the key appears in
custodia on the remote master, we could lose the "IPA server hosts can
create own Custodia secrets" and "IPA server hosts can manage own
Custodia secrets" ACIs from patch 510. Not sure if it's worth the change
though.


Not worth the change, as it has the same security properties.


2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?

If 'member' was used instead, we would gain referential integrity and
the ability to add ACIs based on the attribute (think
userattr="member#USERDN").


To avoid referential integrity and mixup with other group objects, it
was intentional.


3) Why is 'memberPrincipal' used in cn=custodia at all?

The hostname of the replica is already in 'cn', so instead of searching
cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we
could get cn={enc,sig}/$HOSTNAME,cn=custodia directly.


They idea was to be flexible, in a future we might have some shared
keys, then the only way to properly resolve keys would be to use a
multivalued attribute.
Or we may want to have multiple keys sets for the same principal (it
doesn't have to be a host technically, it could be a service or even a
user in the future), and a naming based convention would make it harder
to deal with that.


On the patches
--
509:
- commit says only: "aci: add IPA servers host group 'ipaservers'"
but it does other things like changing how CA renewal certificate acis
are added, I think that must be separated in another patch.

- Why "Manage Host Keytab"  aci has been changed to exclude ipaservers ?


To allow only members of the admins group to manage keytabs of IPA 
servers. This is analogous to how only members of the admins group can 
change passwords of other admins.




- Why adding the host to the ipaservers group is done in the
krbinstance ? I would expect LDAP ops to be mostly done in the
DSinstance.


It is the same place where the host entry is created.



- I do not see where the host is added to the ipaservers group on
upgrade.


It's in install/updates/20-ipaservers_hostgroup.update:

add: member: fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX



510:
- We should probably tightenup the ACI to allos host X to only add
memberPrincipal = X and no other value, also the host should not be
allowed to change the memberPrincipal attribute only the keys.
If we can't express this in ACIs we can live with the ones you propose
though.


I think this can be done.

memberPrincipal is included in the ACI because KEMLdap.set_key() touches 
it. Perhaps it is not intentional?




511:
ack, but I think you should catch potential exceptions from the
os.rmdir, as it will throw if there is some other file in the dir (for
whatever reason). The exception can be safely ignored, we just do not
want to blow up with a traceback here.


OK.



512:
- I do not think this is correct, it seem to me you are overriding the
local ccache (if any) with the host keytab. If I read this right, this
means that if you run kinit admin && ipa-replica-install then you will
kind your admin credentials gone and a host TGT instead. Am I reading
this change correctly ?


No. :-) Temporary ccache is now used for the install and the host is 
kinited into it. The initial ccache is used only for connection check 
(and adding the host to ipaservers in patch 514). Your kinit admin will 
not be lost.




513:
Nack
- Should be folded into 510


These ACIs are required only for patch 514.


- Should not allow all hosts in the domain but only ipaservers for aal
three changes


If the host isn't member of ipaservers before ipa-replica-install is 
run, the "Check that we don't already have a replication agreement", 
"Detect if the other master can handle replication managers" and "Find 
if any server has a CA" steps will fail without these ACIs, which breaks 
patch 514.




514:
- Should be folded in 512, they are completely

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-20 Thread Simo Sorce

On Fri, 2015-11-20 at 16:49 +0100, Jan Cholasta wrote:
> On 19.11.2015 17:43, Simo Sorce wrote:
[..]
> > On the patches
> > --
> > 509:
> > - commit says only: "aci: add IPA servers host group 'ipaservers'"
> > but it does other things like changing how CA renewal certificate acis
> > are added, I think that must be separated in another patch.
> >
> > - Why "Manage Host Keytab"  aci has been changed to exclude ipaservers ?
> 
> To allow only members of the admins group to manage keytabs of IPA 
> servers. This is analogous to how only members of the admins group can 
> change passwords of other admins.

I guess there is an interaction between ACIs I am not getting here, can
you give a small overview of how we end up here ?
If IPAservers are not supposed to access those attributes, why are they
added to the permissions at all ?
Wouldn't it make sense to have 2 set of permissions ?
One for admin type users (with access to all attributes) and one for
less privileged users ?

> > - Why adding the host to the ipaservers group is done in the
> > krbinstance ? I would expect LDAP ops to be mostly done in the
> > DSinstance.
> 
> It is the same place where the host entry is created.

I will translate this with "historical" :-)

> > - I do not see where the host is added to the ipaservers group on
> > upgrade.
> 
> It's in install/updates/20-ipaservers_hostgroup.update:
> 
> add: member: fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX

Ahh, I missed that, thanks!

> > 510:
> > - We should probably tightenup the ACI to allos host X to only add
> > memberPrincipal = X and no other value, also the host should not be
> > allowed to change the memberPrincipal attribute only the keys.
> > If we can't express this in ACIs we can live with the ones you propose
> > though.
> 
> I think this can be done.
> 
> memberPrincipal is included in the ACI because KEMLdap.set_key() touches 
> it. Perhaps it is not intentional?

Yeah, it is a bug in set_key(), of course we need to add memberPrincipal
when creating a whole new entry, but we should not modify it on existing
entries.

> > 511:
> > ack, but I think you should catch potential exceptions from the
> > os.rmdir, as it will throw if there is some other file in the dir (for
> > whatever reason). The exception can be safely ignored, we just do not
> > want to blow up with a traceback here.
> 
> OK.
> 
> >
> > 512:
> > - I do not think this is correct, it seem to me you are overriding the
> > local ccache (if any) with the host keytab. If I read this right, this
> > means that if you run kinit admin && ipa-replica-install then you will
> > kind your admin credentials gone and a host TGT instead. Am I reading
> > this change correctly ?
> 
> No. :-) Temporary ccache is now used for the install and the host is 
> kinited into it. The initial ccache is used only for connection check 
> (and adding the host to ipaservers in patch 514). Your kinit admin will 
> not be lost.

Ok, got it.

> >
> > 513:
> > Nack
> > - Should be folded into 510
> 
> These ACIs are required only for patch 514.

Yes, but they are close and will give a full picture of the change
required for the feature if they are together. They won't hurt anything
even if unused until a few patches later (IIUC).

> > - Should not allow all hosts in the domain but only ipaservers for aal
> > three changes
> 
> If the host isn't member of ipaservers before ipa-replica-install is 
> run, the "Check that we don't already have a replication agreement", 
> "Detect if the other master can handle replication managers" and "Find 
> if any server has a CA" steps will fail without these ACIs, which breaks 
> patch 514.

Yes I understood that, but it is intentional, these are administrative
checks, they need to be done as admin or with a host account that has
been pre-added to the ipaservers group. We do not want to expose
information to all other hosts in the domain as replication agreements
can include passwords in some cases, or other access information the
admin may not want to make available to random hosts.

> > 514:
> > - Should be folded in 512, they are completely interdependent changes.
> 
> Patch 512 works fine without this patch, but the host has to be member 
> of ipaservers before ipa-replica-install is run.

Yeah, this is a problem, we do not want admins to have to do that,
right ?

> > - I do not understand how this works. promote_check() runs before
> > promote() and will fail if the host is not already in the ipaservers
> > group, so you will never be able to actually add the host to the group ?
> > sounds like chicken-egg ... or what am I missing ?
> 
> The chicken-egg is solved by the ACIs from patch 513. They allow any 
> host to perform the checks necessary for promote_check() to succeed, so 
> the host can be added to ipaservers in promote().

I do not see how ACIs solve the problem where the code check if the
server is already in ipaservers, and the server isn't. My reading is
this please tell me where I am wrong:

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-19 Thread Simo Sorce

On Thu, 2015-11-19 at 15:43 +0100, Jan Cholasta wrote:
> Hi,
> 
> the attached patches fix  
> and .
> 
> I worked around the issue of checking if the user is privileged to 
> perform replica promotion by using host credentials instead. The host 
> must be a member of the IPA servers host group "ipaservers" in order to 
> be able to promote itself. Using host credentials will also allow 
> replica install using one-time password.
> 
> User credentials are still used for connection check and to 
> automatically add the host to ipaservers if the user is privileged to do 
> that.
> 
> Simo, is this approach OK? Could you check the new ACIs in patches 510 
> and 513?
> 
> I have a couple of questions:
> 
> 1) Why are custodia keys for the replica added to LDAP using connection 
> to the remote master instead of local ldapi connection? Is it to 
> eliminate race conditions caused by replication timeout from the replica 
> to the remote master?

Yes it is critical for that reason.

> If the code was changed to use ldapi and wait until the key appears in 
> custodia on the remote master, we could lose the "IPA server hosts can 
> create own Custodia secrets" and "IPA server hosts can manage own 
> Custodia secrets" ACIs from patch 510. Not sure if it's worth the change 
> though.

Not worth the change, as it has the same security properties.

> 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?
> 
> If 'member' was used instead, we would gain referential integrity and 
> the ability to add ACIs based on the attribute (think 
> userattr="member#USERDN").

To avoid referential integrity and mixup with other group objects, it
was intentional.

> 3) Why is 'memberPrincipal' used in cn=custodia at all?
> 
> The hostname of the replica is already in 'cn', so instead of searching 
> cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we 
> could get cn={enc,sig}/$HOSTNAME,cn=custodia directly.

They idea was to be flexible, in a future we might have some shared
keys, then the only way to properly resolve keys would be to use a
multivalued attribute.
Or we may want to have multiple keys sets for the same principal (it
doesn't have to be a host technically, it could be a service or even a
user in the future), and a naming based convention would make it harder
to deal with that.


On the patches
--
509:
- commit says only: "aci: add IPA servers host group 'ipaservers'"
but it does other things like changing how CA renewal certificate acis
are added, I think that must be separated in another patch.

- Why "Manage Host Keytab"  aci has been changed to exclude ipaservers ?

- Why adding the host to the ipaservers group is done in the
krbinstance ? I would expect LDAP ops to be mostly done in the
DSinstance.

- I do not see where the host is added to the ipaservers group on
upgrade.

510:
- We should probably tightenup the ACI to allos host X to only add
memberPrincipal = X and no other value, also the host should not be
allowed to change the memberPrincipal attribute only the keys.
If we can't express this in ACIs we can live with the ones you propose
though.

511:
ack, but I think you should catch potential exceptions from the
os.rmdir, as it will throw if there is some other file in the dir (for
whatever reason). The exception can be safely ignored, we just do not
want to blow up with a traceback here.

512:
- I do not think this is correct, it seem to me you are overriding the
local ccache (if any) with the host keytab. If I read this right, this
means that if you run kinit admin && ipa-replica-install then you will
kind your admin credentials gone and a host TGT instead. Am I reading
this change correctly ?

513:
Nack
- Should be folded into 510
- Should not allow all hosts in the domain but only ipaservers for aal
three changes

514:
- Should be folded in 512, they are completely interdependent changes.
- I do not understand how this works. promote_check() runs before
promote() and will fail if the host is not already in the ipaservers
group, so you will never be able to actually add the host to the group ?
sounds like chicken-egg ... or what am I missing ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

2015-11-19 Thread Jan Cholasta


Hi,

the attached patches fix  
and .


I worked around the issue of checking if the user is privileged to 
perform replica promotion by using host credentials instead. The host 
must be a member of the IPA servers host group "ipaservers" in order to 
be able to promote itself. Using host credentials will also allow 
replica install using one-time password.


User credentials are still used for connection check and to 
automatically add the host to ipaservers if the user is privileged to do 
that.


Simo, is this approach OK? Could you check the new ACIs in patches 510 
and 513?


I have a couple of questions:

1) Why are custodia keys for the replica added to LDAP using connection 
to the remote master instead of local ldapi connection? Is it to 
eliminate race conditions caused by replication timeout from the replica 
to the remote master?


If the code was changed to use ldapi and wait until the key appears in 
custodia on the remote master, we could lose the "IPA server hosts can 
create own Custodia secrets" and "IPA server hosts can manage own 
Custodia secrets" ACIs from patch 510. Not sure if it's worth the change 
though.


2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?

If 'member' was used instead, we would gain referential integrity and 
the ability to add ACIs based on the attribute (think 
userattr="member#USERDN").


3) Why is 'memberPrincipal' used in cn=custodia at all?

The hostname of the replica is already in 'cn', so instead of searching 
cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we 
could get cn={enc,sig}/$HOSTNAME,cn=custodia directly.


Honza

--
Jan Cholasta
From fe5cf036513648a6b9398fb118ade33f4cd1b25a Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Wed, 11 Nov 2015 11:01:57 +0100
Subject: [PATCH] aci: add IPA servers host group 'ipaservers'

https://fedorahosted.org/freeipa/ticket/3416
---
 ACI.txt|   4 +-
 install/share/bootstrap-template.ldif  |  11 +++
 install/share/default-aci.ldif |  11 ---
 install/updates/20-ipaservers_hostgroup.update |  10 +++
 install/updates/40-delegation.update   |  18 ++--
 install/updates/Makefile.am|   1 +
 ipalib/plugins/host.py |   6 ++
 ipalib/plugins/hostgroup.py|  26 ++
 ipaserver/install/krbinstance.py   |   7 ++
 ipaserver/install/replication.py   | 111 -
 10 files changed, 75 insertions(+), 130 deletions(-)
 create mode 100644 install/updates/20-ipaservers_hostgroup.update

diff --git a/ACI.txt b/ACI.txt
index 40fa822..bbc2e66 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -119,7 +119,7 @@ aci: (targetattr = "usercertificate")(targetfilter = "(objectclass=ipahost)")(ve
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = "userpassword")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Enrollment Password";allow (write) groupdn = "ldap:///cn=System: Manage Host Enrollment Password,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
-aci: (targetattr = "krblastpwdchange || krbprincipalkey")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab";allow (write) groupdn = "ldap:///cn=System: Manage Host Keytab,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetattr = "krblastpwdchange || krbprincipalkey")(targetfilter = "(&(!(memberOf=cn=ipaservers,cn=hostgroups,cn=accounts,dc=ipa,dc=example))(objectclass=ipahost))")(version 3.0;acl "permission:System: Manage Host Keytab";allow (write) groupdn = "ldap:///cn=System: Manage Host Keytab,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = "createtimestamp || entryusn || ipaallowedtoperform;read_keys || ipaallowedtoperform;write_keys || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab Permissions";allow (compare,read,search,write) groupdn = "ldap:///cn=System: Manage Host Keytab Permissions,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
@@ -137,7 +137,7 @@ aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System
 dn: cn=hostgroups,cn=accounts,dc=ipa,dc=example
 aci: (targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:System: Add Hostgroups";allow (add) groupdn = "ldap:///cn=System: Add Hostgroups,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hostgroups,cn=accounts,dc=ipa,dc=example
-aci: (targetattr = "member")(targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:System: Modify Hostgroup Membership";allow (write) groupdn = "ldap:///cn=System: Modify Hostgroup

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

Re: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

[Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

27 matches

Site Navigation

Mail list logo

Footer information