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
> >> 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.
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
> >> Freeipafirstname.lastname@example.org
> >> https://www.redhat.com/mailman/listinfo/freeipa-devel
> > _______________________________________________
> > Freeipa-devel mailing list
> > Freeipaemail@example.com
> > https://www.redhat.com/mailman/listinfo/freeipa-devel
Freeipa-devel mailing list