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 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. > Yes - me too. > >> > >> 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 > >> [email protected] > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > [email protected] > > https://www.redhat.com/mailman/listinfo/freeipa-devel > _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
