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

Thu Nov 3 13:22:23 UTC 2011

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 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel