[Freeipa-devel] [PATCHES 00012-0013 v7] Profiles and CA ACLs
Fraser Tweedale
ftweedal at redhat.com
Tue Jun 9 07:07:46 UTC 2015
On Thu, Jun 04, 2015 at 03:58:25PM +0200, Martin Basti wrote:
> On 04/06/15 15:48, Martin Kosek wrote:
> >On 06/04/2015 03:40 PM, Martin Basti wrote:
> >>On 04/06/15 08:59, Fraser Tweedale wrote:
> >>>On Wed, Jun 03, 2015 at 06:49:13PM +0200, Martin Basti wrote:
> >>>>On 03/06/15 16:17, Fraser Tweedale wrote:
> >>>>>On Tue, Jun 02, 2015 at 06:37:42PM +0200, Martin Basti wrote:
> >>>>>>On 02/06/15 14:11, Fraser Tweedale wrote:
> >>>>>>>On Mon, Jun 01, 2015 at 05:22:28PM +1000, Fraser Tweedale wrote:
> >>>>>>>>On Mon, Jun 01, 2015 at 05:10:58PM +1000, Fraser Tweedale wrote:
> >>>>>>>>>On Fri, May 29, 2015 at 01:03:46PM +0200, Martin Kosek wrote:
> >>>>>>>>>>On 05/29/2015 11:21 AM, Martin Basti wrote:
> >>>>>>>>>>>On 29/05/15 06:17, Fraser Tweedale wrote:
> >>>>>>>>>>>>On Thu, May 28, 2015 at 02:42:53PM +0200, Martin Basti wrote:
> >>>>>>>>>>>>>On 28/05/15 11:48, Martin Basti wrote:
> >>>>>>>>>>>>>>On 27/05/15 16:04, Fraser Tweedale wrote:
> >>>>>>>>>>>>>>>Hello all,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>Fresh certificate management patchset; Changelog:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>- Now depends on patch freeipa-ftweedal-0014 for correct
> >>>>>>>>>>>>>>>cert-request behaviour with host and service principals.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>- Updated Dogtag dependency to 10.2.4-1. Should should be in
> >>>>>>>>>>>>>>>f22 soon, but for f22 right now or for f21, please grab from my
> >>>>>>>>>>>>>>>copr: https://copr.fedoraproject.org/coprs/ftweedal/freeipa/
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Martin^1 could you please add to the quasi-official freeipa
> >>>>>>>>>>>>>>> copr? SRPM lives at
> >>>>>>>>>>>>>>> https://frase.id.au/pki-core-10.2.4-1.fc21.src.rpm.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>- cert-request now verifies that for user principals, CSR CN
> >>>>>>>>>>>>>>>matches uid and, DN emailAddress and SAN rfc822Name match user's
> >>>>>>>>>>>>>>>email address, if either of those is present.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>- Fixed one or two other sneaky little bugs.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>On Wed, May 27, 2015 at 01:59:30AM +1000, Fraser Tweedale wrote:
> >>>>>>>>>>>>>>>>Hi all,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Please find attached the latest certificate management
> >>>>>>>>>>>>>>>>patchset, which introduces the `caacl' plugin and various fixes
> >>>>>>>>>>>>>>>>and improvement to earlier patches.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>One important change to earlier patches is reverting the name
> >>>>>>>>>>>>>>>>of the default profile to 'caIPAserviceCert' and using the
> >>>>>>>>>>>>>>>>existing instance of this profile on upgrade (but not install)
> >>>>>>>>>>>>>>>>in case it has been modified.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Other notes:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>- Still have changes in ipa-server-install (fewer lines now,
> >>>>>>>>>>>>>>>>though)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>- Still have the ugly import hack. It is not a high priority
> >>>>>>>>>>>>>>>>for me, i.e. I think it should wait until after alpha
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>- Still need to update 'service' and 'host' plugins to support
> >>>>>>>>>>>>>>>>multiple certificates. (The userCertificate attribute schema
> >>>>>>>>>>>>>>>>itself is multi-valued, so there are no schema issues here)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>- The TODOs in [1]; mostly certprofile CLI conveniences and
> >>>>>>>>>>>>>>>>supporting multiple profiles for hosts and services (which
> >>>>>>>>>>>>>>>>requires changes to framework only, not schema). [1]:
> >>>>>>>>>>>>>>>>http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Happy reviewing! I am pleased with the initial cut of the
> >>>>>>>>>>>>>>>>caacl plugin but I'm sure you will find some things to be fixed
> >>>>>>>>>>>>>>>>:)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Cheers, Fraser
> >>>>>>>>>>>>>>[root at vm-093 ~]# ipa-replica-prepare vm-094.example.com
> >>>>>>>>>>>>>>--ip-address 10.34.78.94 Directory Manager (existing master)
> >>>>>>>>>>>>>>password:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Preparing replica for vm-094.example.com from vm-093.example.com
> >>>>>>>>>>>>>>Creating SSL certificate for the Directory Server not well-formed
> >>>>>>>>>>>>>>(invalid token): line 2, column 14
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>I cannot create replica file. It work on the upgraded server,
> >>>>>>>>>>>>>>but it doesn't work on the newly installed server. I'm not sure
> >>>>>>>>>>>>>>if this causes your patches which modifies the ca-installer, or
> >>>>>>>>>>>>>>the newer version of dogtag.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Or if there was any other changes in master, I will continue to
> >>>>>>>>>>>>>>investigate with new RPM from master branch.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Martin^2
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>ipa-replica-prepare works for: * master branch * master branch +
> >>>>>>>>>>>>>pki-ca 10.2.4-1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>So something in your patches is breaking it
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>Martin^2
> >>>>>>>>>>>>>
> >>>>>>>>>>>>Martin, master + my patches with pki 10.2.4-1 is working for me on
> >>>>>>>>>>>>f21 and f22. Can you provide ipa-replica-prepare --debug output and
> >>>>>>>>>>>>Dogtag debug log? ( /var/log/pki/pki-tomcat/ca/debug )
> >>>>>>>>>>>>
> >>>>>>>>>>>>Thanks,
> >>>>>>>>>>>>Fraser
> >>>>>>>>>>>I can not reproduce it today. And I already recycled the VMs from
> >>>>>>>>>>>yesterday. :-(
> >>>>>>>>>>>
> >>>>>>>>>>In that case I would suggest ACKing&pushing the patch and fixing the
> >>>>>>>>>>bug if
> >>>>>>>>>>it comes again. The tree may now be a bit unstable, given the number of
> >>>>>>>>>>patches going in.
> >>>>>>>>>>
> >>>>>>>>>>My main motivation here is to unblock Fraser.
> >>>>>>>>>>
> >>>>>>>>>>Thanks,
> >>>>>>>>>>Martin
> >>>>>>>>>Rebased patchset attached; no other changes.
> >>>>>>>>Heads up: I just discovered I have introduced a bug with
> >>>>>>>>ipa-replica-install, when it is spawning the CA instance. I think
> >>>>>>>>replication it only causes issues with ``--setup-ca``.
> >>>>>>>>
> >>>>>>>>I will try and sort it out tomorrow or later tonight (I have to head
> >>>>>>>>out for a few hours now, though); and I'm not suggesting it should
> >>>>>>>>block the push but it's something to be aware of.
> >>>>>>>>
> >>>>>>>>Cheers,
> >>>>>>>>Fraser
> >>>>>>>>
> >>>>>>>New patchset attached ; haven't gotten to the bottom of the
> >>>>>>>ipa-replica-install issue mentioned above, but it fixes an upgrade
> >>>>>>>bug.
> >>>>>>>
> >>>>>>>The change is:
> >>>>>>>
> >>>>>>>diff --git a/ipaserver/install/server/upgrade.py
> >>>>>>>b/ipaserver/install/server/upgrade.py
> >>>>>>>index c288282..c5f4d37 100644
> >>>>>>>--- a/ipaserver/install/server/upgrade.py
> >>>>>>>+++ b/ipaserver/install/server/upgrade.py
> >>>>>>>@@ -316,7 +316,7 @@ def ca_enable_ldap_profile_subsystem(ca):
> >>>>>>> caconfig.CS_CFG_PATH,
> >>>>>>> directive,
> >>>>>>> separator='=')
> >>>>>>>- if value == 'ProfileSubsystem':
> >>>>>>>+ if value == 'com.netscape.cmscore.profile.ProfileSubsystem':
> >>>>>>> needs_update = True
> >>>>>>> break
> >>>>>>> except OSError, e:
> >>>>>>>@@ -328,7 +328,7 @@ def ca_enable_ldap_profile_subsystem(ca):
> >>>>>>> installutils.set_directive(
> >>>>>>> caconfig.CS_CFG_PATH,
> >>>>>>> directive,
> >>>>>>>- 'LDAPProfileSubsystem',
> >>>>>>>+ 'com.netscape.cmscore.profile.LDAPProfileSubsystem',
> >>>>>>> quotes=False,
> >>>>>>> separator='=')
> >>>>>>>
> >>>>>>>Cheers,
> >>>>>>>Fraser
> >>>>>>>
> >>>>>>>
> >>>>>>Thank you,
> >>>>>>
> >>>>>>1)
> >>>>>>ipa-getcert request (getcert -c IPA)
> >>>>>>doesnt work,
> >>>>>>
> >>>>>>Request ID '20150602145845':
> >>>>>> status: CA_REJECTED
> >>>>>> ca-error: Server at https://vm-137.example.com/ipa/xml denied our
> >>>>>>request, giving up: 3007 (RPC failed at server. 'profile_id' is required).
> >>>>>>
> >>>>>>2)
> >>>>>>Error from rpm install
> >>>>>>Unexpected error - see /var/log/ipaupgrade.log for details:
> >>>>>>SkipPluginModule: dogtag not selected as RA plugin
> >>>>>>
> >>>>>>Just for record as known issue, this will be fixed later in a new patch.
> >>>>>>
> >>>>>>3)
> >>>>>>+ Str('profile_id', validate_profile_id,
> >>>>>>+ label=_("Profile ID"),
> >>>>>>+ doc=_("Certificate Profile to use"),
> >>>>>>+ )
> >>>>>>Please mark this param as optional. ('profile_id?')
> >>>>>>This will fix issue 1, but 1 will need a option to specify profile_id
> >>>>>>
> >>>>>>Also move API related change from patch 9 to patch 11 + increment VERSION
> >>>>>>
> >>>>>>4)
> >>>>>>* Maybe I do everything wrong :)
> >>>>>>
> >>>>>> I'm not able to create certificate stored in FILE, via ipa-getcert request.
> >>>>>>I'm getting error:
> >>>>>>status: CA_UNREACHABLE
> >>>>>> ca-error: Server at https://vm-137.example.com/ipa/xml failed request,
> >>>>>>will retry: 4001 (RPC failed at server. vm-137.example.com at example.com: host
> >>>>>>not found).
> >>>>>>
> >>>>>>or error:
> >>>>>>Request ID '20150602154115':
> >>>>>> status: CA_REJECTED
> >>>>>> ca-error: Server at https://vm-137.example.com/ipa/xml denied our
> >>>>>>request, giving up: 2100 (RPC failed at server. Insufficient access: not
> >>>>>>allowed to perform this command).
> >>>>>>(I'm root and kinited as admin)
> >>>>>>
> >>>>>>Maybe additional ACI is required for cert_request as it is VirtualCommand
> >>>>>>
> >>>>>>
> >>>>>>--
> >>>>>>Martin Basti
> >>>>>>
> >>>>>Thanks for report. Attached patchset should fix the certmonger
> >>>>>issues, and also makes cert-request --profile-id argument optional.
> >>>>>
> >>>>>The changes were fixup'd into the appropriate patches but the
> >>>>>combined diff follows. (Note that the API.txt and VERSION changes
> >>>>>you recommended were executed but are missing from this diff.)
> >>>>>
> >>>>>Thanks,
> >>>>>Fraser
> >>>>>
> >>>>>diff --git a/ipalib/plugins/caacl.py b/ipalib/plugins/caacl.py
> >>>>>index c09df86..a9dde86 100644
> >>>>>--- a/ipalib/plugins/caacl.py
> >>>>>+++ b/ipalib/plugins/caacl.py
> >>>>>@@ -12,7 +12,7 @@ from ipalib.plugins.baseldap import (
> >>>>> LDAPUpdate, LDAPRetrieve, LDAPAddMember, LDAPRemoveMember,
> >>>>> pkey_to_value)
> >>>>> from ipalib.plugins.certprofile import validate_profile_id
> >>>>>-from ipalib.plugins.service import normalize_principal
> >>>>>+from ipalib.plugins.service import normalize_principal, split_any_principal
> >>>>> from ipalib import _, ngettext
> >>>>> from ipapython.dn import DN
> >>>>>@@ -69,7 +69,7 @@ def _acl_make_request(principal_type, principal, ca_ref,
> >>>>>profile_id):
> >>>>> groups = user_obj.get('memberof_group', [])
> >>>>> groups += user_obj.get('memberofindirect_group', [])
> >>>>> elif principal_type == 'host':
> >>>>>- hostname = principal[5:]
> >>>>>+ service, hostname, realm = split_any_principal(principal)
> >>>>> host_obj = api.Command.host_show(hostname)['result']
> >>>>> groups = host_obj.get('memberof_hostgroup', [])
> >>>>> groups += host_obj.get('memberofindirect_hostgroup', [])
> >>>>>diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py
> >>>>>index 70ae610..1878e5a 100644
> >>>>>--- a/ipalib/plugins/cert.py
> >>>>>+++ b/ipalib/plugins/cert.py
> >>>>>@@ -247,7 +247,7 @@ class cert_request(VirtualCommand):
> >>>>> default=False,
> >>>>> autofill=True
> >>>>> ),
> >>>>>- Str('profile_id', validate_profile_id,
> >>>>>+ Str('profile_id?', validate_profile_id,
> >>>>> label=_("Profile ID"),
> >>>>> doc=_("Certificate Profile to use"),
> >>>>> )
> >>>>>@@ -346,7 +346,14 @@ class cert_request(VirtualCommand):
> >>>>> bind_principal = split_any_principal(getattr(context, 'principal'))
> >>>>> bind_service, bind_name, bind_realm = bind_principal
> >>>>>- if bind_principal != principal:
> >>>>>+ if bind_service is None:
> >>>>>+ bind_principal_type = USER
> >>>>>+ elif bind_service == 'host':
> >>>>>+ bind_principal_type = HOST
> >>>>>+ else:
> >>>>>+ bind_principal_type = SERVICE
> >>>>>+
> >>>>>+ if bind_principal != principal and bind_principal_type != HOST:
> >>>>> # Can the bound principal request certs for another principal?
> >>>>> self.check_access()
> >>>>>@@ -359,7 +366,7 @@ class cert_request(VirtualCommand):
> >>>>> error=_("Failure decoding Certificate Signing Request:
> >>>>>%s") % e)
> >>>>> # host principals may bypass allowed ext check
> >>>>>- if bind_service != 'host':
> >>>>>+ if bind_principal_type != HOST:
> >>>>> for ext in extensions:
> >>>>> operation = self._allowed_extensions.get(ext)
> >>>>> if operation:
> >>>>>diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py
> >>>>>index 659751e..53085f7 100644
> >>>>>--- a/ipapython/dogtag.py
> >>>>>+++ b/ipapython/dogtag.py
> >>>>>@@ -47,7 +47,7 @@ INCLUDED_PROFILES = {
> >>>>> (u'caIPAserviceCert', u'Standard profile for network services', True),
> >>>>> }
> >>>>>-DEFAULT_PROFILE = 'caIPAserviceCert'
> >>>>>+DEFAULT_PROFILE = u'caIPAserviceCert'
> >>>>> class Dogtag10Constants(object):
> >>>>> DOGTAG_VERSION = 10
> >>>>Should the user certificates behave in the same way as host and service
> >>>>certificates, i.e should be revoked after user-del or user-mod operation??
> >>>>If yes it would be an additional patch.
> >>>>
> >>>>Please move API.txt fragment from patch 9 to patch 11
> >>>>With this change ACK for patches 1-11, to unblock testing. For patches 12-13
> >>>>I need more time.
> >>>>
> >>>>--
> >>>>Martin Basti
> >>>>
> >>>Updated patches attached. Only your requested change for 1-11. For
> >>>12-13 (caacl plugin) it was updated to LDAPAddMember and
> >>>LDAPRemoveMember functionality for adding profiles to ACL - this has
> >>>the desirable effect of making sure the profile actually exists :)
> >>>
> >>>Thanks,
> >>>Fraser
> >>Hello,
> >>
> >>design page needs upgrade
> >>
> >>Please fix
> >>1)
> >>ngettext/ugettext missing? (several times)
> >>('%i object added.', '%i objects added.')
> >>
> >>2)
> >> --allprofiles=BOOL Allow use of all profiles
> >> --allusers=BOOL Allow all users
> >> --allhosts=BOOL Allow all hosts
> >> --allservices=BOOL Allow all services
> >>
> >>Other commands use the separate words with '-', I suggest to use
> >>--all-profiles=True, etc..
> >For these, should we follow the example in hbacrule or sudorule:
> >
> ># ipa hbacrule-mod --help
> >Usage: ipa [global-options] hbacrule-mod NAME [options]
> >
> >Modify an HBAC rule.
> >Options:
> > -h, --help show this help message and exit
> > --usercat=['all'] User category the rule applies to
> > --hostcat=['all'] Host category the rule applies to
> > --servicecat=['all'] Service category the rule applies to
> >
> >i.e. what I think Martin describes in 4)
> >
> >>3)
> >>In the following example, there is missing ACL name:
> >>+ ipa caacl-add-user --user=alice
> >>
> >>4)
> >>attributes 'ipaCaAclAllCAs', 'ipaCaAclAllProfiles', 'ipaCaAclAllUsers',
> >>'ipaCaAclAllHosts', 'ipaCaAclAllServices' should be called ipaCaAclCAsCategory,
> >>etc... to be consistent, please reuse usercategory, hostcategory, etc. and
> >>create new category attribute definitions for the rest.
> >>Please read sudorule.py for details.
> >>Respectively instead BOOLEAN True, the value 'all' should be there. This allows
> >>to extend it in future.
> >>
> >>5)
> >>Missing referint plugin configuration for attribute 'ipacaaclmembercertprofile'
> >>Please add it into install/updates/25-referint.update (+ other member
> >>attributes if missing)
> >>
> >>6)
> >>ACI:
> >>'memberhostgroup' is not virtual nor real attribute, please remove it from
> >>there (Honza told me there is an error in HBAC ipa plugin, I will send fix)
> >>
> 7)
> Missing upgrade?
>
> + self.step("creating default CA ACL rule", self.add_caacl)
>
> This was added to dsinstance, but I cannot found it in upgrade.
>
What heuristic should we use? We only ever want to add it on the
first upgrade. Is it appropriate to do something like this:
if sysupgrade.get_upgrade_state(...):
return
acls = search_caacls_in_ldap()
if not acls:
add_default_acl()
sysupgrade.set_upgrade_state(..., True)
This will only ever try to add the default ACL once, and it will
only actually add it if there are no caacl objects.
Next problem - I tried to implement the above but always had LDAP
connection problems. What is the sure-fire way to talk to LDAP
during upgrade process?
Cheers,
Fraser
More information about the Freeipa-devel
mailing list