[Freeipa-devel] [PATCHES 00012-0013 v7] Profiles and CA ACLs
Martin Basti
mbasti at redhat.com
Tue Jun 9 10:28:59 UTC 2015
On 09/06/15 09:07, Fraser Tweedale wrote:
> 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.
IMO yes, looks good.
> 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?
You can use api.Backend.ldap2 connection, as is used in add_ca_dns_records.
>
> Cheers,
> Fraser
--
Martin Basti
More information about the Freeipa-devel
mailing list