[Freeipa-devel] [PATCHES 247-259] ID views - management part
Hi, the following set of patches implements the ID view creation and management of views and ID overrides in IPA. Pending questions: 1.) The patch 253 implements basic managed permissions for ID views and ID overrides. Do we want to have a separate permission for assigning ID views? 2.) Performance: idview-apply command takes ~100 seconds for hostgroups with 1000 member hosts. I am able to lower that by 20-30% using raw ldap calls, is bypassing the framework worth the performance gain? We'll lose the possiblity to hook on exception callbacks. The commands also need more helpful documentation, I am working on that. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org >From 00289142b3eff9474cbb6672c17abad1c6b63005 Mon Sep 17 00:00:00 2001 From: Tomas Babej Date: Thu, 31 Jul 2014 11:57:53 +0200 Subject: [PATCH] idviews: Add necessary schema for the ID views --- install/share/60basev2.ldif| 4 +++- install/share/71idviews.ldif | 5 + install/share/Makefile.am | 1 + install/share/copy-schema-to-ca.py | 1 + ipaserver/install/dsinstance.py| 1 + 5 files changed, 11 insertions(+), 1 deletion(-) create mode 100644 install/share/71idviews.ldif diff --git a/install/share/60basev2.ldif b/install/share/60basev2.ldif index 044acc413984b78ef71da8f24f86ffca611d5d43..60174caf19b6d463729b66cabf0c64b9b798955d 100644 --- a/install/share/60basev2.ldif +++ b/install/share/60basev2.ldif @@ -12,8 +12,10 @@ attributeTypes: (2.16.840.1.113730.3.8.3.18 NAME 'managedBy' DESC 'DNs of entrie attributeTypes: (2.16.840.1.113730.3.8.3.24 NAME 'ipaEntitlementId' DESC 'Entitlement Unique identifier' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' ) # ipaKrbAuthzData added here. Even though it is a v3 attribute it is updating # a v2 objectClass so needs to be here. +# Same for the ipaAssignedIDView. attributeTypes: (2.16.840.1.113730.3.8.11.37 NAME 'ipaKrbAuthzData' DESC 'type of PAC preferred by a service' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) -objectClasses: (2.16.840.1.113730.3.8.4.1 NAME 'ipaHost' AUXILIARY MUST ( fqdn ) MAY ( userPassword $ ipaClientVersion $ enrolledBy $ memberOf $ userClass ) X-ORIGIN 'IPA v2' ) +attributeTypes: (2.16.840.1.113730.3.8.12.32 NAME 'ipaAssignedIDView' DESC 'DN of view assigned to this particular host' SUP distinguishedName EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4' ) +objectClasses: (2.16.840.1.113730.3.8.4.1 NAME 'ipaHost' AUXILIARY MUST ( fqdn ) MAY ( userPassword $ ipaClientVersion $ enrolledBy $ memberOf $ userClass $ ipaAssignedIDView ) X-ORIGIN 'IPA v2' ) objectClasses: (2.16.840.1.113730.3.8.4.12 NAME 'ipaObject' DESC 'IPA objectclass' AUXILIARY MUST ( ipaUniqueID ) X-ORIGIN 'IPA v2' ) objectClasses: (2.16.840.1.113730.3.8.4.14 NAME 'ipaEntitlement' DESC 'IPA Entitlement object' AUXILIARY MUST ( ipaEntitlementId ) MAY ( userPKCS12 $ userCertificate ) X-ORIGIN 'IPA v2' ) objectClasses: (2.16.840.1.113730.3.8.4.15 NAME 'ipaPermission' DESC 'IPA Permission objectclass' AUXILIARY MAY ( ipaPermissionType ) X-ORIGIN 'IPA v2' ) diff --git a/install/share/71idviews.ldif b/install/share/71idviews.ldif new file mode 100644 index ..bb9dec551aa1952000ea17eea2da767ab9d0621d --- /dev/null +++ b/install/share/71idviews.ldif @@ -0,0 +1,5 @@ +dn: cn=schema +attributeTypes: (2.16.840.1.113730.3.8.11.62 NAME 'ipaAnchorUUID' DESC 'Unique Anchor Identifier' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v4') +objectClasses: (2.16.840.1.113730.3.8.12.29 NAME 'ipaOverrideAnchor' SUP top STRUCTURAL MUST ( cn $ description $ ipaAnchorUUID ) X-ORIGIN 'IPA v4' ) +objectClasses: (2.16.840.1.113730.3.8.12.30 NAME 'ipaUserOverride' DESC 'Override for User Attributes' SUP ipaOverrideAnchor STRUCTURAL MAY ( uid $ uidNumber $ gidNumber $ homeDirectory $ loginShell $ gecos ) X-ORIGIN 'IPA v4' ) +objectClasses: (2.16.840.1.113730.3.8.12.31 NAME 'ipaGroupOverride' DESC 'Override for Group Attributes' SUP ipaOverrideAnchor STRUCTURAL MAY ( gidNumber ) X-ORIGIN 'IPA v4' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 7d5b67a78020e8445277162ec585fd908be17de4..e72623ad7ada2763ef44d44fa9ab436f21e97eb5 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -19,6 +19,7 @@ app_DATA =\ 65ipacertstore.ldif \ 65ipasudo.ldif \ 70ipaotp.ldif \ + 71idviews.ldif \ anonymous-vlv.ldif \ bootstrap-template.ldif \ caJarSigningCert.cfg.template \ diff --git a/install/share/copy-schema-to-ca.py b/install/share/copy-schema-to-ca.py index fc53fe4cb52486cc618bec77aabe8283ad5eadbc..c795bf6d47b13da95dfb1c518bb3b45c0c173521 100755 --- a/install/share/copy-schema-to-
Re: [Freeipa-devel] LDAP schema for DNSSEC keys
On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote: > I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going > to comment the steps from the link above here: I think anyone with a fedora login can change it, but thanks anyway, you clarified quite some things. I have a questions about algorithms agility though, are we tied to use AES128 and RSA2048 ? Or do we have the means to specify and use alternative algorithms should it be necessary ? (Like EC instead of RSA ?) Also would you know where I can find details on how CKM_AES_KEY_WRAP[_PAD] is actually implemented ? 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] LDAP schema for DNSSEC keys
On 08/01/2014 01:54 PM, Simo Sorce wrote: > On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote: > >> I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going >> to comment the steps from the link above here: > > I think anyone with a fedora login can change it, but thanks anyway, you > clarified quite some things. Yup. Wiki edits are allowed for all authenticated users, check "Edit this page" button at the bottom of the page. Honza, please add your clarification to the page, as we can see - it clarifies a lot. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for DNSSEC keys
Dne 1.8.2014 v 13:54 Simo Sorce napsal(a): On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote: I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going to comment the steps from the link above here: I think anyone with a fedora login can change it, but thanks anyway, you clarified quite some things. I have a questions about algorithms agility though, are we tied to use AES128 and RSA2048 ? Or do we have the means to specify and use alternative algorithms should it be necessary ? (Like EC instead of RSA ?) The schema allows different key types and wrapping algorithms to be used in the future. Also would you know where I can find details on how CKM_AES_KEY_WRAP[_PAD] is actually implemented ? CKM_AES_KEY_WRAP uses the algorithm specified in RFC 3394, CKM_AES_KEY_WRAP_PAD uses the algorithm described in RFC 5649. We don't use CKM_AES_KEY_WRAP ATM. Simo. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for DNSSEC keys
On Fri, 2014-08-01 at 14:31 +0200, Jan Cholasta wrote: > Dne 1.8.2014 v 13:54 Simo Sorce napsal(a): > > On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote: > > > >> I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going > >> to comment the steps from the link above here: > > > > I think anyone with a fedora login can change it, but thanks anyway, you > > clarified quite some things. > > > > I have a questions about algorithms agility though, are we tied to use > > AES128 and RSA2048 ? Or do we have the means to specify and use > > alternative algorithms should it be necessary ? > > (Like EC instead of RSA ?) > > The schema allows different key types and wrapping algorithms to be used > in the future. Excellent > > > > Also would you know where I can find details on how > > CKM_AES_KEY_WRAP[_PAD] is actually implemented ? > > CKM_AES_KEY_WRAP uses the algorithm specified in RFC 3394, > CKM_AES_KEY_WRAP_PAD uses the algorithm described in RFC 5649. We don't > use CKM_AES_KEY_WRAP ATM. Thanks. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 481 ipa-adtrust-install does not re-add member in adtrust agents
When a CIFS service exists and adtrust agents group does not
have it as a member attribute (for whatever reason), re-running
ipa-adtrust-install does not fix the inconsistency.
Make the installer more robust by being able to fix the inconsistency.
https://fedorahosted.org/freeipa/ticket/4464
--
Martin Kosek
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.
From 42775635daa6994d1e7d6809ebd205bc7e43779d Mon Sep 17 00:00:00 2001
From: Martin Kosek
Date: Fri, 1 Aug 2014 16:34:33 +0200
Subject: [PATCH] ipa-adtrust-install does not re-add member in adtrust agents
group
When a CIFS service exists and adtrust agents group does not
have it as a member attribute (for whatever reason), re-running
ipa-adtrust-install does not fix the inconsistency.
Make the installer more robust by being able to fix the inconsistency.
https://fedorahosted.org/freeipa/ticket/4464
---
ipaserver/install/adtrustinstance.py | 39 +++-
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py
index 7cfc5e886eaea23ac1527bddc5a15bea5edf9d8c..38b0801314c3c98438ce4d07cdb54059dde94ce9 100644
--- a/ipaserver/install/adtrustinstance.py
+++ b/ipaserver/install/adtrustinstance.py
@@ -497,28 +497,31 @@ def __write_smb_registry(self):
def __setup_principal(self):
try:
api.Command.service_add(unicode(self.cifs_principal))
-# Add the principal to the 'adtrust agents' group
-# as 389-ds only operates with GroupOfNames, we have to use
-# the principal's proper dn as defined in self.cifs_agent
-try:
-current = self.admin_conn.get_entry(self.smb_dn)
-members = current.get('member', [])
-if not(self.cifs_agent in members):
-current["member"] = members + [self.cifs_agent]
-self.admin_conn.update_entry(current)
-except errors.NotFound:
-entry = self.admin_conn.make_entry(
-self.smb_dn,
-objectclass=["top", "GroupOfNames"],
-cn=[self.smb_dn['cn']],
-member=[self.cifs_agent],
-)
-self.admin_conn.add_entry(entry)
-except Exception:
+except errors.DuplicateEntry:
# CIFS principal already exists, it is not the first time
# adtrustinstance is managed
# That's fine, we we'll re-extract the key again.
pass
+except Exception, e:
+self.print_msg("Cannot add CIFS service: %s" % e)
+
+# Add the principal to the 'adtrust agents' group
+# as 389-ds only operates with GroupOfNames, we have to use
+# the principal's proper dn as defined in self.cifs_agent
+try:
+current = self.admin_conn.get_entry(self.smb_dn)
+members = current.get('member', [])
+if not(self.cifs_agent in members):
+current["member"] = members + [self.cifs_agent]
+self.admin_conn.update_entry(current)
+except errors.NotFound:
+entry = self.admin_conn.make_entry(
+self.smb_dn,
+objectclass=["top", "GroupOfNames"],
+cn=[self.smb_dn['cn']],
+member=[self.cifs_agent],
+)
+self.admin_conn.add_entry(entry)
self.clean_samba_keytab()
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 481 ipa-adtrust-install does not re-add member in adtrust agents
On Fri, 01 Aug 2014, Martin Kosek wrote: When a CIFS service exists and adtrust agents group does not have it as a member attribute (for whatever reason), re-running ipa-adtrust-install does not fix the inconsistency. Make the installer more robust by being able to fix the inconsistency. https://fedorahosted.org/freeipa/ticket/4464 ACK. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Password Vault Implementation
On 7/31/2014 5:34 PM, Simo Sorce wrote:
I think you misunderstood what I was proposing.
I was proposing the vault is the unit of encryption, as a single blob of
data. But the vault would still contain multiple secrets, simply
formatted into a json object.
Something like:
plaintext:
{
{ id: "email",
data: "Passw0rd",
description: "my email password"
},
{ id: "redhat.com",
data: "Secret5",
description: "redhat.com website password"
},
...
}
OK, understood. This means in the service use case the service vault
password will have to be provisioned to service instances using separate
vaults that use asymmetric encryption key. This type of vaults will
become a "drop box" and will not support escrow.
Any concern about the crypto operations being computationally expensive,
or retrieving the whole blob just to see the metadata would waste bandwidth?
How big do you think the vault would be ?
It is not meant to contain anything more than a bunch of passwords, do
we really have a problem if the blob is a few tens of kilobytes ?
I can't say how people will use it, but regardless, we can configure the
size limit on the server.
Given service passwords is an actual use case I think /services should
be a top level namespace available by default.
OK. Any preference how the service vaults should be structured?
* /services/@ -> repetitive server name?
* /services// -> more organized
Is this going to be the service drop box (to provision the service vault
password) or the service vault (that the instance is going to access
using the service vault password)? Or will the instances access a shared
service vault?
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Password Vault Implementation
On Fri, 2014-08-01 at 10:28 -0500, Endi Sukma Dewata wrote:
> On 7/31/2014 5:34 PM, Simo Sorce wrote:
> > I think you misunderstood what I was proposing.
> > I was proposing the vault is the unit of encryption, as a single blob of
> > data. But the vault would still contain multiple secrets, simply
> > formatted into a json object.
> >
> > Something like:
> >
> > plaintext:
> > {
> > { id: "email",
> >data: "Passw0rd",
> >description: "my email password"
> > },
> > { id: "redhat.com",
> >data: "Secret5",
> >description: "redhat.com website password"
> > },
> >...
> > }
>
> OK, understood. This means in the service use case the service vault
> password will have to be provisioned to service instances using separate
> vaults that use asymmetric encryption key. This type of vaults will
> become a "drop box" and will not support escrow.
I do not understand why escrow would not be supported, can you
elaborate ?
> >> Any concern about the crypto operations being computationally expensive,
> >> or retrieving the whole blob just to see the metadata would waste
> >> bandwidth?
> >
> > How big do you think the vault would be ?
> > It is not meant to contain anything more than a bunch of passwords, do
> > we really have a problem if the blob is a few tens of kilobytes ?
>
> I can't say how people will use it, but regardless, we can configure the
> size limit on the server.
Right
> > Given service passwords is an actual use case I think /services should
> > be a top level namespace available by default.
>
> OK. Any preference how the service vaults should be structured?
> * /services/@ -> repetitive server name?
> * /services// -> more organized
The latter seem to make more sense to me.
> Is this going to be the service drop box (to provision the service vault
> password) or the service vault (that the instance is going to access
> using the service vault password)? Or will the instances access a shared
> service vault?
Good questions, I am not sure.
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] Password Vault Implementation
On 8/1/2014 12:21 PM, Simo Sorce wrote: OK, understood. This means in the service use case the service vault password will have to be provisioned to service instances using separate vaults that use asymmetric encryption key. This type of vaults will become a "drop box" and will not support escrow. I do not understand why escrow would not be supported, can you elaborate ? See http://www.freeipa.org/page/V4/Password_Vault#Escrow_Workflows. With a normal vault (symmetric key) the secrets will be encrypted with a symmetric secret key, then the secret key itself will be encrypted with the escrow officer's public key and stored on the server. On recovery the escrow officer will decrypt the encrypted secret key with the private key, and use it to decrypt the secrets. I suppose with a drop box (asymmetric key) the secrets themselves will be encrypted with the public key of the owner (i.e. the service instance), not the escrow officer. The secrets can only be retrieved/recovered using the owner's private key. There's no secret key to escrow, unless we want to escrow the owner's private key? OK. Any preference how the service vaults should be structured? * /services/@ -> repetitive server name? * /services// -> more organized The latter seem to make more sense to me. Is this going to be the service drop box (to provision the service vault password) or the service vault (that the instance is going to access using the service vault password)? Or will the instances access a shared service vault? Good questions, I am not sure. Unless there's an objection I'll use it as a drop box. I think each service instance should have a mechanism to configure the vaults it's going to use anyway, so we don't have to decide this now. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Password Vault Implementation
On Fri, 2014-08-01 at 14:42 -0500, Endi Sukma Dewata wrote: > On 8/1/2014 12:21 PM, Simo Sorce wrote: > >> OK, understood. This means in the service use case the service vault > >> password will have to be provisioned to service instances using separate > >> vaults that use asymmetric encryption key. This type of vaults will > >> become a "drop box" and will not support escrow. > > > > I do not understand why escrow would not be supported, can you > > elaborate ? > > See http://www.freeipa.org/page/V4/Password_Vault#Escrow_Workflows. > > With a normal vault (symmetric key) the secrets will be encrypted with a > symmetric secret key, then the secret key itself will be encrypted with > the escrow officer's public key and stored on the server. On recovery > the escrow officer will decrypt the encrypted secret key with the > private key, and use it to decrypt the secrets. > > I suppose with a drop box (asymmetric key) the secrets themselves will > be encrypted with the public key of the owner (i.e. the service > instance), not the escrow officer. The secrets can only be > retrieved/recovered using the owner's private key. There's no secret key > to escrow, unless we want to escrow the owner's private key? The service can create a symmetric key and encrypt it with its public key and the escrow public key. > >> OK. Any preference how the service vaults should be structured? > >> * /services/@ -> repetitive server name? > >> * /services// -> more organized > > > > The latter seem to make more sense to me. > > > >> Is this going to be the service drop box (to provision the service vault > >> password) or the service vault (that the instance is going to access > >> using the service vault password)? Or will the instances access a shared > >> service vault? > > > > Good questions, I am not sure. > > Unless there's an objection I'll use it as a drop box. I think each > service instance should have a mechanism to configure the vaults it's > going to use anyway, so we don't have to decide this now. I am not sure having no escrow is good, often services are given secrets need to connect to third parties so escrow may be important in case the service private key is lost accidentally. 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] Password Vault Implementation
On 8/1/2014 2:45 PM, Simo Sorce wrote: On Fri, 2014-08-01 at 14:42 -0500, Endi Sukma Dewata wrote: On 8/1/2014 12:21 PM, Simo Sorce wrote: OK, understood. This means in the service use case the service vault password will have to be provisioned to service instances using separate vaults that use asymmetric encryption key. This type of vaults will become a "drop box" and will not support escrow. I do not understand why escrow would not be supported, can you elaborate ? See http://www.freeipa.org/page/V4/Password_Vault#Escrow_Workflows. With a normal vault (symmetric key) the secrets will be encrypted with a symmetric secret key, then the secret key itself will be encrypted with the escrow officer's public key and stored on the server. On recovery the escrow officer will decrypt the encrypted secret key with the private key, and use it to decrypt the secrets. I suppose with a drop box (asymmetric key) the secrets themselves will be encrypted with the public key of the owner (i.e. the service instance), not the escrow officer. The secrets can only be retrieved/recovered using the owner's private key. There's no secret key to escrow, unless we want to escrow the owner's private key? The service can create a symmetric key and encrypt it with its public key and the escrow public key. Not sure I understand. How does the admin provision the service vault password to the instance? How does the instance retrieve the service vault password? How does the escrow officer recover the service vault password? OK. Any preference how the service vaults should be structured? * /services/@ -> repetitive server name? * /services// -> more organized The latter seem to make more sense to me. Is this going to be the service drop box (to provision the service vault password) or the service vault (that the instance is going to access using the service vault password)? Or will the instances access a shared service vault? Good questions, I am not sure. Unless there's an objection I'll use it as a drop box. I think each service instance should have a mechanism to configure the vaults it's going to use anyway, so we don't have to decide this now. I am not sure having no escrow is good, often services are given secrets need to connect to third parties so escrow may be important in case the service private key is lost accidentally. Those secrets probably should be stored in the service vault (which will be accessed using the service vault password) instead of in the drop box. That service vault will support normal escrow since it's using symmetric key. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
