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
