On 11/03/2011 11:30 AM, Andrew Wnuk wrote:
On 11/02/2011 03:19 PM, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote:
On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote:
[...]
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.
Sounds reasonable.
Can you post a link to the schema that would be added to IPA objects ?
Simo.
IIRC the user we create in CS now has the description attribute set
up in a very specific way. Is that still required?
rob
Steps 1 to 3 should have an option to be performed only by CS admins
with certificate client authentication, otherwise we will break rules
of secure CS configuration including separation of roles.
We had a long talk about that on the IPA call this morning.
In order to add someone to the PKIAdmin user-group, you need to have
the appropriate ACIs. We'd like to lock thos in, so that someone
messing around with IPA can't mess them up.
I'm not certain that the specific authentication mechanism is the issue
so much as you need to have a guarantee of authentication no less than
what Client Cert auth gives you. Kerberos authentication should
actually be as good: it will be enforced not just by the application,
but all the way down to the DS instance via ACIs.
Andrew
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
