Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On 11/03/2011 12:56 AM, Simo Sorce wrote: On Wed, 2011-11-02 at 20:25 -0400, Adam Young wrote: On 11/02/2011 06:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. I think this is it: http://svn.fedorahosted.org/svn/pki/trunk/pki/base/ca/shared/conf/schema.ldif Look for cmsuser. Unfortunately it looks like the cmsuser objectclass is of type structural, which means it cannot be added to existing records. The cert seems to comes from 05rfc4523.ldif and is added in 06inetorgperson.ldif Which is already in our user record. CMS only seems to require usertype, which is a string, and allows userstate which is an integer. I wonder if we can convince PKI to use a different schema to reprsent this information. We can use Roles or Groups to tell what type of user a user is, not sure about the state as that schema file has exactly the same comment for both usertype and userstate, seems a bug. I think so. I do not know if CMSuser is really needed, as it looks like everything in there is accounted for some other way. My guess is the type field is used to enforce that someone in one group, say agents, cannot also be in a different group, say auditors but they do use groups for most roles in the system. I think that there are going to be severl layers for the permissions in the IPA approach: For CAAdmins, we create a group CAdmins, and add a Role to to CAAdminRole which contains the appropriate Permissions. Same for Auditors and agents. No one should have the ACI to change these roles. We probably want to put in an RFE for IPA Roles that state two roles are mutually exclusive. userstate is, I think, to disable an account, which is handled using nsaccount lock in IPA. I think we should agree on a single mechanism, and it should be the one in the most standard schema. IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? What is description used for ? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: To clarify: there are two types of Data stored in the PKI CA DS instances. One is Users and groups (IdM), and the other is certificates and requests. The CA currently administers its own users: creates, add deletes, add privs and so forth. If we extract the IdM objects from the CA control, we will need to build another mechanism to manage them. The Certificates will stay in their own suffix. I don't think anyone disagrees about this. I'm trying to think through the steps of using the IPA user database for PKI. If I undertand the end state, the general flow will be driven from ipa-server-install and will look like this: 1. Create a unified DS instance. We can continue to name it the way that IPA does: All caps the hostname. 2. Apply the LDAP schema LDIFs to it. At this point, we probably want to create the whole IPA schema, and the cmsUser as well For clarification, cmsuser is just an object that is defined in the PKI schema, not the actual admin user created in the install itself. It may be advantageous to actually pre-create this user when applying schema LDIFS and just have pkisilent add the user certs. The description attribute needs to store per-instance specific information such as the requestId. Unless you mean just adding userstate and usertype. 3. Call PKISilent (or equivalent) passing the info for the Unified directory server instance, to include the IPA tree for the users. 4. PKISilent will create the PKI admin user, to include its certificiate in the IPA tree. This user will be half baked from an IPA perspective, but will allow administration of the CA. Pre-creating this user may solve this problem. You can pre-create a user with all the required IPA and PKI attributes and just have pkisilent add the user cert needed. As we will be running as directory manager in this case, we will permissions to do this. 5. Create a PKIDirectory Manager account that has complete control over only the PKI suffix, and not the IPA suffix. Modify the PKI code to use only this account. This account should be able to authenticate against the Dir Srv using a client certificate, stored in the PKI specific NSS database. This of course involves setting up the relevant ACIs. We may want to consider the reverse. That only certain IPA accounts should have access to the PKI data. Which still involves ACIs, right? 6. Restart the CA. 7. Continue the IPA server install from the. Fix up the Admin user so that it works for IPA. Not needed if we pre-populate as mentioned above. 8. Disable the Directory Manager's password. From here on out, access to the Dir Srv should be either certificate or Keytab only. After IPA is up and running, the management of the User Database is done by IPA. One thing that several people have asked for in IPA is the ability to manage external Roles: ones that don't map to ACIs. PKI has this requirement as well. There are a couple approaches we could take: 1. Attempt to use the current Role mechanism in IPA. This gets hidden to an outside user, but that should be OK. Checking if a user is a PKI Admin, Agent, or Auditor should be done only by a privileged account anyway. 2. Use a User Group: PKIAdmins, PKIAgents, and PKIAuditors.This is what I would suggest. 3. Create an external mechanism. Once IPA has assumed control of the IdM DB, we will still need to be able to get user certificates into the user records CMSUser field. I do not know CS well enough to say how that would work, but I assume it will be one of these two mechanisms: 1. Use the CA Administrative interface to modify an existing user to have the certificate or 2. Add a mechanism to IPA to request and apply the certificate to the IPA User. I'm guessing that the flow would be something like this: 1. Create a user (ipa user-add) 2. Assign them to the PKIAgents groups 3. Call the CA Admin interface to make the user an agent. If we do it this way, the PKI instance will need to be able to modify the IPA user record. Alternatively: 1. ipa user-add 2. ipa group-add-member 3. ipa user-cert So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. And it never should IMHO. We need to maintain the idea that the CA is some black box that we can poke at from time to time to get data but I'd prefer to keep them discrete. As an added bonus, we get user certs. One discussion we've had on the side is about scalability. As the Databases
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Thu, 2011-11-03 at 09:20 -0400, Adam Young wrote: On 11/03/2011 12:56 AM, Simo Sorce wrote: On Wed, 2011-11-02 at 20:25 -0400, Adam Young wrote: On 11/02/2011 06:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. I think this is it: http://svn.fedorahosted.org/svn/pki/trunk/pki/base/ca/shared/conf/schema.ldif Look for cmsuser. Unfortunately it looks like the cmsuser objectclass is of type structural, which means it cannot be added to existing records. The cert seems to comes from 05rfc4523.ldif and is added in 06inetorgperson.ldif Which is already in our user record. CMS only seems to require usertype, which is a string, and allows userstate which is an integer. I wonder if we can convince PKI to use a different schema to reprsent this information. We can use Roles or Groups to tell what type of user a user is, not sure about the state as that schema file has exactly the same comment for both usertype and userstate, seems a bug. I think so. I do not know if CMSuser is really needed, as it looks like everything in there is accounted for some other way. My guess is the type field is used to enforce that someone in one group, say agents, cannot also be in a different group, say auditors but they do use groups for most roles in the system. I think that there are going to be severl layers for the permissions in the IPA approach: For CAAdmins, we create a group CAdmins, and add a Role to to CAAdminRole which contains the appropriate Permissions. Same for Auditors and agents. No one should have the ACI to change these roles. We probably want to put in an RFE for IPA Roles that state two roles are mutually exclusive. userstate is, I think, to disable an account, which is handled using nsaccount lock in IPA. I think we should agree on a single mechanism, and it should be the one in the most standard schema. With just an initial look at the dogtag code, it appears that userState and userType are no longer used in any meaningful way. We'll have to do a more exhaustive search to be sure, but initial indications are that we may no longer need this object class. Adam does bring up a good point, which is that - as a common criteria requirement, users were required to have no more than one of the following roles: agent, admin, auditor. How would this be enforced in the IPA database? IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? What is description used for ? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On 11/03/2011 11:00 AM, Ade Lee wrote: On Thu, 2011-11-03 at 09:20 -0400, Adam Young wrote: On 11/03/2011 12:56 AM, Simo Sorce wrote: On Wed, 2011-11-02 at 20:25 -0400, Adam Young wrote: On 11/02/2011 06:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. I think this is it: http://svn.fedorahosted.org/svn/pki/trunk/pki/base/ca/shared/conf/schema.ldif Look for cmsuser. Unfortunately it looks like the cmsuser objectclass is of type structural, which means it cannot be added to existing records. The cert seems to comes from 05rfc4523.ldif and is added in 06inetorgperson.ldif Which is already in our user record. CMS only seems to require usertype, which is a string, and allows userstate which is an integer. I wonder if we can convince PKI to use a different schema to reprsent this information. We can use Roles or Groups to tell what type of user a user is, not sure about the state as that schema file has exactly the same comment for both usertype and userstate, seems a bug. I think so. I do not know if CMSuser is really needed, as it looks like everything in there is accounted for some other way. My guess is the type field is used to enforce that someone in one group, say agents, cannot also be in a different group, say auditors but they do use groups for most roles in the system. I think that there are going to be severl layers for the permissions in the IPA approach: For CAAdmins, we create a group CAdmins, and add a Role to to CAAdminRole which contains the appropriate Permissions. Same for Auditors and agents. No one should have the ACI to change these roles. We probably want to put in an RFE for IPA Roles that state two roles are mutually exclusive. userstate is, I think, to disable an account, which is handled using nsaccount lock in IPA. I think we should agree on a single mechanism, and it should be the one in the most standard schema. With just an initial look at the dogtag code, it appears that userState and userType are no longer used in any meaningful way. We'll have to do a more exhaustive search to be sure, but initial indications are that we may no longer need this object class. Adam does bring up a good point, which is that - as a common criteria requirement, users were required to have no more than one of the following roles: agent, admin, auditor. How would this be enforced in the IPA database? I think that we need to make it an RFE for IPA. IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? What is description used for ? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Thu, 2011-11-03 at 11:00 -0400, Ade Lee wrote: On Thu, 2011-11-03 at 09:20 -0400, Adam Young wrote: On 11/03/2011 12:56 AM, Simo Sorce wrote: On Wed, 2011-11-02 at 20:25 -0400, Adam Young wrote: On 11/02/2011 06:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. I think this is it: http://svn.fedorahosted.org/svn/pki/trunk/pki/base/ca/shared/conf/schema.ldif Look for cmsuser. Unfortunately it looks like the cmsuser objectclass is of type structural, which means it cannot be added to existing records. The cert seems to comes from 05rfc4523.ldif and is added in 06inetorgperson.ldif Which is already in our user record. CMS only seems to require usertype, which is a string, and allows userstate which is an integer. I wonder if we can convince PKI to use a different schema to reprsent this information. We can use Roles or Groups to tell what type of user a user is, not sure about the state as that schema file has exactly the same comment for both usertype and userstate, seems a bug. I think so. I do not know if CMSuser is really needed, as it looks like everything in there is accounted for some other way. My guess is the type field is used to enforce that someone in one group, say agents, cannot also be in a different group, say auditors but they do use groups for most roles in the system. I think that there are going to be severl layers for the permissions in the IPA approach: For CAAdmins, we create a group CAdmins, and add a Role to to CAAdminRole which contains the appropriate Permissions. Same for Auditors and agents. No one should have the ACI to change these roles. We probably want to put in an RFE for IPA Roles that state two roles are mutually exclusive. userstate is, I think, to disable an account, which is handled using nsaccount lock in IPA. I think we should agree on a single mechanism, and it should be the one in the most standard schema. With just an initial look at the dogtag code, it appears that userState and userType are no longer used in any meaningful way. We'll have to do a more exhaustive search to be sure, but initial indications are that we may no longer need this object class. Adam does bring up a good point, which is that - as a common criteria requirement, users were required to have no more than one of the following roles: agent, admin, auditor. How would this be enforced in the IPA database? At the moment it can't be enforced, but I guess we could build a special plugin that will work similarly to the uniqueness plugin but will work on one or more pools of mutually exclusive roles to be enforced on all entries. I guess this is something that could be useful outside of CA as well if roles turns out to be used more. 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] Unifying the PKI and IPA Directory Server instances
On Thu, 2011-11-03 at 09:22 -0400, Rob Crittenden wrote: Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: To clarify: there are two types of Data stored in the PKI CA DS instances. One is Users and groups (IdM), and the other is certificates and requests. The CA currently administers its own users: creates, add deletes, add privs and so forth. If we extract the IdM objects from the CA control, we will need to build another mechanism to manage them. The Certificates will stay in their own suffix. I don't think anyone disagrees about this. I'm trying to think through the steps of using the IPA user database for PKI. If I undertand the end state, the general flow will be driven from ipa-server-install and will look like this: 1. Create a unified DS instance. We can continue to name it the way that IPA does: All caps the hostname. 2. Apply the LDAP schema LDIFs to it. At this point, we probably want to create the whole IPA schema, and the cmsUser as well For clarification, cmsuser is just an object that is defined in the PKI schema, not the actual admin user created in the install itself. It may be advantageous to actually pre-create this user when applying schema LDIFS and just have pkisilent add the user certs. The description attribute needs to store per-instance specific information such as the requestId. Unless you mean just adding userstate and usertype. In dogtag, I believe we have used the description attribute to store whatever the user provided to describe the user/group. This is more relevant to the console. As IPA will be managing users and groups, then it can also manage this attribute. 3. Call PKISilent (or equivalent) passing the info for the Unified directory server instance, to include the IPA tree for the users. 4. PKISilent will create the PKI admin user, to include its certificiate in the IPA tree. This user will be half baked from an IPA perspective, but will allow administration of the CA. Pre-creating this user may solve this problem. You can pre-create a user with all the required IPA and PKI attributes and just have pkisilent add the user cert needed. As we will be running as directory manager in this case, we will permissions to do this. 5. Create a PKIDirectory Manager account that has complete control over only the PKI suffix, and not the IPA suffix. Modify the PKI code to use only this account. This account should be able to authenticate against the Dir Srv using a client certificate, stored in the PKI specific NSS database. This of course involves setting up the relevant ACIs. We may want to consider the reverse. That only certain IPA accounts should have access to the PKI data. Which still involves ACIs, right? Right 6. Restart the CA. 7. Continue the IPA server install from the. Fix up the Admin user so that it works for IPA. Not needed if we pre-populate as mentioned above. 8. Disable the Directory Manager's password. From here on out, access to the Dir Srv should be either certificate or Keytab only. After IPA is up and running, the management of the User Database is done by IPA. One thing that several people have asked for in IPA is the ability to manage external Roles: ones that don't map to ACIs. PKI has this requirement as well. There are a couple approaches we could take: 1. Attempt to use the current Role mechanism in IPA. This gets hidden to an outside user, but that should be OK. Checking if a user is a PKI Admin, Agent, or Auditor should be done only by a privileged account anyway. 2. Use a User Group: PKIAdmins, PKIAgents, and PKIAuditors.This is what I would suggest. 3. Create an external mechanism. Once IPA has assumed control of the IdM DB, we will still need to be able to get user certificates into the user records CMSUser field. I do not know CS well enough to say how that would work, but I assume it will be one of these two mechanisms: 1. Use the CA Administrative interface to modify an existing user to have the certificate or 2. Add a mechanism to IPA to request and apply the certificate to the IPA User. I'm guessing that the flow would be something like this: 1. Create a user (ipa user-add) 2. Assign them to the PKIAgents groups 3. Call the CA Admin interface to make the user an agent. If we do it this way, the PKI instance will need to be able to modify the IPA user record. Alternatively: 1. ipa user-add 2. ipa group-add-member 3. ipa user-cert So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On 11/02/2011 03:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? rob Steps 1 to 3 should have an option to be performed only by CS admins with certificate client authentication, otherwise we will break rules of secure CS configuration including separation of roles. Andrew ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On 11/03/2011 11:30 AM, Andrew Wnuk wrote: On 11/02/2011 03:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? rob Steps 1 to 3 should have an option to be performed only by CS admins with certificate client authentication, otherwise we will break rules of secure CS configuration including separation of roles. We had a long talk about that on the IPA call this morning. In order to add someone to the PKIAdmin user-group, you need to have the appropriate ACIs. We'd like to lock thos in, so that someone messing around with IPA can't mess them up. I'm not certain that the specific authentication mechanism is the issue so much as you need to have a guarantee of authentication no less than what Client Cert auth gives you. Kerberos authentication should actually be as good: it will be enforced not just by the application, but all the way down to the DS instance via ACIs. Andrew ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On 11/01/2011 10:08 AM, Ade Lee wrote: On Tue, 2011-11-01 at 12:49 -0400, Simo Sorce wrote: On Tue, 2011-11-01 at 12:40 -0400, Richard Megginson wrote: - Original Message - We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: Do IPA and PKI use different suffixes? Currently not as we use completely separate instances, but we will be able to use different suffixes for some stuff. I would suggest that if we use the same database, then we use different suffixes. For one thing, we will want to be able to set ACIs so that the information here is not publicly browsable. It will also be much easier to limit the pki users ability to touch the rest of the db, and visa versa. It also makes it less likely that upgrade scripts will stomp on each other. We really should use separate suffixes/backends for the reasons above in addition to other benefits. Replication is at the suffix level, so this adds the ability to not replicate PKI data is that is something we ever decide we need to do. Indexes are also configured at the suffix/backend level, so we can have separate indexes defined for the PKI and IPA user trees. 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin It may be easy to enhance this plugin and other plugins to allow different configuration per subtree. If we confirm this conflict this will become a requirement before we can proceed. What is this conflict? Many of our plug-ins have this ability already, and we should add it where it is missing. The RHDS documentation shows that the attribute uniqueness plug-in can be configured by subtree already. 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? Or use ldapi? I don't think ldapjdk can use ldapi. It's a matter of trust for me. I do not want to trust PKI to have free reign on all data. I want it to be confined to only what it needs. So we can use ldapi and user mapping, but we wouldn't map the user to DM anyway. Agreed. If the roles were reversed, we would not want IPA to be able to have free reign on the PKI data. It makes sense to have separate admin roles and only use DM where absolutely necessary. 3. Index strategies are different Use a union? e.g. if ipa needs attribute a indexed for equality only, but PKI needs it indexed for presence and substring only, then we can just index it for eq, sub, and pres. If we use separate suffixes/backends, we can configure the indexes differently. The problem here is finding out and how to make sure pki vs ds/ipa install and upgrade scripts do not stomp on each other. 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context What is this? See my other mail, we need DS to support setting defaultNamingContext in rootdse. Is there a RFE opened against 389 for this already? It should be pretty easy to add the ability to configure a default naming context to be displayed in the rootDSE. 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) If both PKI and IPA use structural objectclasses, we may have to create corresponding auxiliary objectclasses so that you can mix-in both sets of objectclasses while having only one structural objectclass per entry. The problem here is much bigger, PKI simply do not have enough information to create a proper IPA user, so it should not be allowed to. This is an example of why I want to tightly control through ACIs what PKI can do and prevent it from causing issues. If we do this integration, then I'm OK with IPA creating the users. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
To clarify: there are two types of Data stored in the PKI CA DS instances. One is Users and groups (IdM), and the other is certificates and requests. The CA currently administers its own users: creates, add deletes, add privs and so forth. If we extract the IdM objects from the CA control, we will need to build another mechanism to manage them. The Certificates will stay in their own suffix. I don't think anyone disagrees about this. I'm trying to think through the steps of using the IPA user database for PKI. If I undertand the end state, the general flow will be driven from ipa-server-install and will look like this: 1. Create a unified DS instance. We can continue to name it the way that IPA does: All caps the hostname. 2. Apply the LDAP schema LDIFs to it. At this point, we probably want to create the whole IPA schema, and the cmsUser as well 3. Call PKISilent (or equivalent) passing the info for the Unified directory server instance, to include the IPA tree for the users. 4. PKISilent will create the PKI admin user, to include its certificiate in the IPA tree. This user will be half baked from an IPA perspective, but will allow administration of the CA. 5. Create a PKIDirectory Manager account that has complete control over only the PKI suffix, and not the IPA suffix. Modify the PKI code to use only this account. This account should be able to authenticate against the Dir Srv using a client certificate, stored in the PKI specific NSS database. 6. Restart the CA. 7. Continue the IPA server install from the. Fix up the Admin user so that it works for IPA. 8. Disable the Directory Manager's password. From here on out, access to the Dir Srv should be either certificate or Keytab only. After IPA is up and running, the management of the User Database is done by IPA. One thing that several people have asked for in IPA is the ability to manage external Roles: ones that don't map to ACIs. PKI has this requirement as well. There are a couple approaches we could take: 1. Attempt to use the current Role mechanism in IPA. This gets hidden to an outside user, but that should be OK. Checking if a user is a PKI Admin, Agent, or Auditor should be done only by a privileged account anyway. 2. Use a User Group: PKIAdmins, PKIAgents, and PKIAuditors.This is what I would suggest. 3. Create an external mechanism. Once IPA has assumed control of the IdM DB, we will still need to be able to get user certificates into the user records CMSUser field. I do not know CS well enough to say how that would work, but I assume it will be one of these two mechanisms: 1. Use the CA Administrative interface to modify an existing user to have the certificate or 2. Add a mechanism to IPA to request and apply the certificate to the IPA User. I'm guessing that the flow would be something like this: 1. Create a user (ipa user-add) 2. Assign them to the PKIAgents groups 3. Call the CA Admin interface to make the user an agent. If we do it this way, the PKI instance will need to be able to modify the IPA user record. Alternatively: 1. ipa user-add 2. ipa group-add-member 3. ipa user-cert As an added bonus, we get user certs. One discussion we've had on the side is about scalability. As the Databases increase in size, it might become impractical to fully synchroize the user database over to a machine that is dedicated to Certificate operations. For example, we might have a public facing machine in the DMZ that is servering CRLs and OCSP to the world. This machine would only need the subset of users that can act as PKI admins. In this case, we might build a custom script for replicating a subset of the IPA data one direction only: from one of the fully replicated instance to the DMZ instance. This is not something we foresee doing in a near term release, but should be discussed and fleshed out. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: To clarify: there are two types of Data stored in the PKI CA DS instances. One is Users and groups (IdM), and the other is certificates and requests. The CA currently administers its own users: creates, add deletes, add privs and so forth. If we extract the IdM objects from the CA control, we will need to build another mechanism to manage them. The Certificates will stay in their own suffix. I don't think anyone disagrees about this. I'm trying to think through the steps of using the IPA user database for PKI. If I undertand the end state, the general flow will be driven from ipa-server-install and will look like this: 1. Create a unified DS instance. We can continue to name it the way that IPA does: All caps the hostname. 2. Apply the LDAP schema LDIFs to it. At this point, we probably want to create the whole IPA schema, and the cmsUser as well For clarification, cmsuser is just an object that is defined in the PKI schema, not the actual admin user created in the install itself. It may be advantageous to actually pre-create this user when applying schema LDIFS and just have pkisilent add the user certs. 3. Call PKISilent (or equivalent) passing the info for the Unified directory server instance, to include the IPA tree for the users. 4. PKISilent will create the PKI admin user, to include its certificiate in the IPA tree. This user will be half baked from an IPA perspective, but will allow administration of the CA. Pre-creating this user may solve this problem. You can pre-create a user with all the required IPA and PKI attributes and just have pkisilent add the user cert needed. As we will be running as directory manager in this case, we will permissions to do this. 5. Create a PKIDirectory Manager account that has complete control over only the PKI suffix, and not the IPA suffix. Modify the PKI code to use only this account. This account should be able to authenticate against the Dir Srv using a client certificate, stored in the PKI specific NSS database. This of course involves setting up the relevant ACIs. We may want to consider the reverse. That only certain IPA accounts should have access to the PKI data. 6. Restart the CA. 7. Continue the IPA server install from the. Fix up the Admin user so that it works for IPA. Not needed if we pre-populate as mentioned above. 8. Disable the Directory Manager's password. From here on out, access to the Dir Srv should be either certificate or Keytab only. After IPA is up and running, the management of the User Database is done by IPA. One thing that several people have asked for in IPA is the ability to manage external Roles: ones that don't map to ACIs. PKI has this requirement as well. There are a couple approaches we could take: 1. Attempt to use the current Role mechanism in IPA. This gets hidden to an outside user, but that should be OK. Checking if a user is a PKI Admin, Agent, or Auditor should be done only by a privileged account anyway. 2. Use a User Group: PKIAdmins, PKIAgents, and PKIAuditors.This is what I would suggest. 3. Create an external mechanism. Once IPA has assumed control of the IdM DB, we will still need to be able to get user certificates into the user records CMSUser field. I do not know CS well enough to say how that would work, but I assume it will be one of these two mechanisms: 1. Use the CA Administrative interface to modify an existing user to have the certificate or 2. Add a mechanism to IPA to request and apply the certificate to the IPA User. I'm guessing that the flow would be something like this: 1. Create a user (ipa user-add) 2. Assign them to the PKIAgents groups 3. Call the CA Admin interface to make the user an agent. If we do it this way, the PKI instance will need to be able to modify the IPA user record. Alternatively: 1. ipa user-add 2. ipa group-add-member 3. ipa user-cert So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. As an added bonus, we get user certs. One discussion we've had on the side is about scalability. As the Databases increase in size, it might become impractical to fully synchroize the user database over to a machine that is dedicated to Certificate operations. For example, we might have a public facing machine in the DMZ that is servering CRLs and OCSP to the world. This machine would
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? 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] Unifying the PKI and IPA Directory Server instances
Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On 11/02/2011 06:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. I think this is it: http://svn.fedorahosted.org/svn/pki/trunk/pki/base/ca/shared/conf/schema.ldif Look for cmsuser. The cert seems to comes from 05rfc4523.ldif and is added in 06inetorgperson.ldif Which is already in our user record. CMS only seems to require usertype, which is a string, and allows userstate which is an integer. IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Wed, 2011-11-02 at 20:25 -0400, Adam Young wrote: On 11/02/2011 06:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. I think this is it: http://svn.fedorahosted.org/svn/pki/trunk/pki/base/ca/shared/conf/schema.ldif Look for cmsuser. Unfortunately it looks like the cmsuser objectclass is of type structural, which means it cannot be added to existing records. The cert seems to comes from 05rfc4523.ldif and is added in 06inetorgperson.ldif Which is already in our user record. CMS only seems to require usertype, which is a string, and allows userstate which is an integer. I wonder if we can convince PKI to use a different schema to reprsent this information. We can use Roles or Groups to tell what type of user a user is, not sure about the state as that schema file has exactly the same comment for both usertype and userstate, seems a bug. IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? What is description used for ? 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] Unifying the PKI and IPA Directory Server instances
We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? 3. Index strategies are different 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) 7. PKI puts users in groups using member of so that should still work for the IPA tree ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On 11/01/2011 12:12 PM, Adam Young wrote: We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? 3. Index strategies are different 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) 7. PKI puts users in groups using member of so that should still work for the IPA tree ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel One additional point: 8. make sure that Certificate Server and IPA upgrade mechanisms for DirSrv don't conflict ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
- Original Message - We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: Do IPA and PKI use different suffixes? 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin It may be easy to enhance this plugin and other plugins to allow different configuration per subtree. 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? Or use ldapi? I don't think ldapjdk can use ldapi. 3. Index strategies are different Use a union? e.g. if ipa needs attribute a indexed for equality only, but PKI needs it indexed for presence and substring only, then we can just index it for eq, sub, and pres. 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context What is this? 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) If both PKI and IPA use structural objectclasses, we may have to create corresponding auxiliary objectclasses so that you can mix-in both sets of objectclasses while having only one structural objectclass per entry. 7. PKI puts users in groups using “member of” so that should still work for the IPA tree ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Tue, 2011-11-01 at 12:12 -0400, Adam Young wrote: We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? Not only insecure but we do not want necessarily trust PKI to touch stuff that is IPA specific. 3. Index strategies are different 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context This is a DS/IPA feature, not a PKI feature. In an IPA install we will need to be able to tell DS that the IPA namingContext is the default one. 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) No it should never be allowed to create users, it should just use existing users I think. 7. PKI puts users in groups using “member of” so that should still work for the IPA tree PKI is currently using groupOfUniqueUsers and uniqueMember. We will need it to use groupOfNames (as modified in 389DS to not require members) and use member (which will automatically create memberof attributes). 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] Unifying the PKI and IPA Directory Server instances
On Tue, 2011-11-01 at 12:40 -0400, Richard Megginson wrote: - Original Message - We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: Do IPA and PKI use different suffixes? Currently not as we use completely separate instances, but we will be able to use different suffixes for some stuff. 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin It may be easy to enhance this plugin and other plugins to allow different configuration per subtree. If we confirm this conflict this will become a requirement before we can proceed. 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? Or use ldapi? I don't think ldapjdk can use ldapi. It's a matter of trust for me. I do not want to trust PKI to have free reign on all data. I want it to be confined to only what it needs. So we can use ldapi and user mapping, but we wouldn't map the user to DM anyway. 3. Index strategies are different Use a union? e.g. if ipa needs attribute a indexed for equality only, but PKI needs it indexed for presence and substring only, then we can just index it for eq, sub, and pres. The problem here is finding out and how to make sure pki vs ds/ipa install and upgrade scripts do not stomp on each other. 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context What is this? See my other mail, we need DS to support setting defaultNamingContext in rootdse. 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) If both PKI and IPA use structural objectclasses, we may have to create corresponding auxiliary objectclasses so that you can mix-in both sets of objectclasses while having only one structural objectclass per entry. The problem here is much bigger, PKI simply do not have enough information to create a proper IPA user, so it should not be allowed to. This is an example of why I want to tightly control through ACIs what PKI can do and prevent it from causing issues. 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] Unifying the PKI and IPA Directory Server instances
On Tue, 2011-11-01 at 12:49 -0400, Simo Sorce wrote: On Tue, 2011-11-01 at 12:40 -0400, Richard Megginson wrote: - Original Message - We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: Do IPA and PKI use different suffixes? Currently not as we use completely separate instances, but we will be able to use different suffixes for some stuff. I would suggest that if we use the same database, then we use different suffixes. For one thing, we will want to be able to set ACIs so that the information here is not publicly browsable. It will also be much easier to limit the pki users ability to touch the rest of the db, and visa versa. It also makes it less likely that upgrade scripts will stomp on each other. 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin It may be easy to enhance this plugin and other plugins to allow different configuration per subtree. If we confirm this conflict this will become a requirement before we can proceed. 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? Or use ldapi? I don't think ldapjdk can use ldapi. It's a matter of trust for me. I do not want to trust PKI to have free reign on all data. I want it to be confined to only what it needs. So we can use ldapi and user mapping, but we wouldn't map the user to DM anyway. 3. Index strategies are different Use a union? e.g. if ipa needs attribute a indexed for equality only, but PKI needs it indexed for presence and substring only, then we can just index it for eq, sub, and pres. The problem here is finding out and how to make sure pki vs ds/ipa install and upgrade scripts do not stomp on each other. 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context What is this? See my other mail, we need DS to support setting defaultNamingContext in rootdse. 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) If both PKI and IPA use structural objectclasses, we may have to create corresponding auxiliary objectclasses so that you can mix-in both sets of objectclasses while having only one structural objectclass per entry. The problem here is much bigger, PKI simply do not have enough information to create a proper IPA user, so it should not be allowed to. This is an example of why I want to tightly control through ACIs what PKI can do and prevent it from causing issues. If we do this integration, then I'm OK with IPA creating the users. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
