With the right credentials (ie not by default) it would be useful to allow ipa-getkeytab to simply fetch existing crdentials instead of always generating new ones. This would help in restore situations or in clusters where multiple machines need exactly the same key. Probably only privileged admins should be allowed to do this.
Related to #233 and #3860
3.4 development was shifted for one month, moving tickets to reflect reality better.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1007367 (RHEL RFE)
In order to authorize the operation we'll need to add some metadata and ACIs to the system. The current approach will test adding a new AUXILIARY objectlass that specifies a couple of attributes to list permitted DNs (users or groups) and a special attribute that represents the operation to authorize but is not necessarily stored in the entry, it is needed only to perform checks in a flexible way in the plugin.
This objectclass will be used to create a special SUFFIX level ACI in the cn=accounts container that will look like this (split on multiple lines for readability):
(targetattr=protectedOperation;getKeytab) (version 3.0; acl "allowed retrieval of keytabs"; allow (read) userattr = "allowedToPerform;getKeytab#GROUPDN";)
We may need to duplicate it with the USERDN specifier too.
The allowedToPerform attribute is multivalued and the sytntax support DNs, the protectedOperation attribute is a string. The subtype is used to allow one objectclass to cover multiple operations, in this case we identify 'getKeytab" as the operation to protect.
Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.
This ticket is not complete yet, moving to next month milestone.
For reference, initial patches were sent here:
master:
Folow up ticket to add CLI/UI for the authorization part: #4419.
Metadata Update from @simo: - Issue assigned to simo - Issue set to the milestone: FreeIPA 4.0 - 2014/06
Login to comment on this ticket.