[Freeipa-devel] Unifying the PKI and IPA Directory Server instances

[Adam Young]

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.