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
[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
