[Freeipa-devel] [PATCH 0243] ipalib: idrange: Make non-implemented range types fail the
Hi,
The ipa-ipa-trust and ipa-ad-winsync ID Range types were allowed to
pass the validation tests, however, they are not implemented nor
checked by the 389 server plugin.
https://fedorahosted.org/freeipa/ticket/4323
--
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 8753bdcd775eb94bc0d9823a1dd1a1a3ea4697c7 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Mon, 16 Jun 2014 17:33:12 +0200
Subject: [PATCH] ipalib: idrange: Make non-implemented range types fail the
validation
The ipa-ipa-trust and ipa-ad-winsync ID Range types were allowed to
pass the validation tests, however, they are not implemented nor
checked by the 389 server plugin.
https://fedorahosted.org/freeipa/ticket/4323
---
ipalib/plugins/idrange.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index 8ffe7bf9afa31c013a76d4cb758a54b1bf1340ec..9e0481e94048c465f9a86112378a47390de0d494 100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -185,13 +185,14 @@ class idrange(LDAPObject):
label = _('ID Ranges')
label_singular = _('ID Range')
+# The commented range types are planned but not yet supported
range_types = {
u'ipa-local': unicode(_('local domain range')),
-u'ipa-ad-winsync': unicode(_('Active Directory winsync range')),
+# u'ipa-ad-winsync': unicode(_('Active Directory winsync range')),
u'ipa-ad-trust': unicode(_('Active Directory domain range')),
u'ipa-ad-trust-posix': unicode(_('Active Directory trust range with '
'POSIX attributes')),
-u'ipa-ipa-trust': unicode(_('IPA trust range')),
+# u'ipa-ipa-trust': unicode(_('IPA trust range')),
}
takes_params = (
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
On 07/14/2014 11:45 AM, Ade Lee wrote:
Hi all,
I have rebased all the previous patches against master, and have squashed them
all into a single patch.
Its a large patch, but as many folks have already reviewed the constituent
precursor patches, most if it
should be familiar and easier to review.
I think it would be nice to have the fixes that aren't related to DRM
(e.g. style issues) separate, so the patch can be reverted easily. But,
what's done is done. Thanks for the cleanup!
The main difference with what was specified before is that the DRM database is
installed as a subtree
to o=ipaca. This means that no new replication agreements will be needed to
replicate DRM data.
Replication agreements set up for the Dogtag CA will automatically replicate
DRM data.
In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed -
with specific changes to
allow the ability to install a database as a subtree of an existing tree. At
this time, these
changes have not yet been checked into the dogtag source. You can obtain such
a build from:
http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/
Please review,
I've started reading the code; here are my thoughts on the first part:
In ipa-ca-install and ipa-replica-install, you only ever set
REPLICA_INFO_TOP_DIR to None. In Python, global has module scope,
it's not for the entire process. (And it's bad practice anyway.)
You'll need to pass it around explicitly, perhaps store it in ReplicaConfig.
It would be nice to use the admintool framework for the new script,
instead of copying the old boilerplate code again. See e.g.
ipa-server-certinstall for an example.
Logging functions interpolate their arguments, so you should use e.g.
root_logger.critical(failed to configure %s instance %s,
subsystem, e)
instead of using the % operator.
installutils.create_replica_config: Any time you call sys.exit(), please
log a message so we know why the log file ends.
In ipa-drm-install, why do you read /etc/ipa/default.conf manually? The
information is available in api.env once api is finalized.
In ipa-server-install, do we want to display the message about backing
up /root/drmcert.p12 even if DRM is not installed?
Please use path constants from ipaplatform.base.paths, or add new ones
if necessary, instead of DogtagInstance.{AGENT_P12_PATH,AGENT_P12_PATH}.
In ipa-upgradeconfig, you hardcoded '/etc/named.keytab'. Please change
that back to paths.NAMED_KEYTAB.
Same in CAInstance.uninstall with /usr/bin/pkiremove.
In ipa-upgradeconfig.find_subject_base, the docstring should mention to
DsInstance.find_subject_base's docstring rather than being a copy; we
dont' want them getting out of sync.
In DsInstance.find_subject_base, don't use a bare `except:`, at least do
`except Exception:`, so you don't e.g. disable Ctrl+C.
In CADSInstance.uninstall, you don't need the _running and _user_exists
variables at all, just call the functions.
Same in CAInstance.__create_ra_agent_db for _stdout, _stderr, _returncode.
Same in CAInstance.uninstall for _user_exists.
In DogtagInstance, stop_tracking_certificates was moved here from
cainstance, but it no longer stops tracking ipaCert in HTTPD_ALIAS_DIR.
Is that intended?
In CAInstance.__init__, when calling DogtagInstance.__init__, consider
using super, and naming the arguments for clarity:
super(CAInstance, self).__init__(
realm=realm,
subsystem=CA,
service_desc=certificate server,
dogtag_constants=dogtag_constants,
)
Since CAInstance inherits from DogtagInstance, the `enable`,
`start_instance`, `stop_instance`, `http_proxy` methods that just call
the superclass are unnecessary.
IMO the comment from CAInstance.__enable was important, it should be in
DogtagInstance.enable.
In DogtagInstance.spawn_instance, it's not nice to modify lists the
caller pased in. Take a copy of the nolog first. Ideally combine that
with the conversion to tuple, and allow any sequence to be passed in:
nolog_list = tuple(nolog_list) + (self.admin_password,
self.dm_password)
In CAInstance.__create_ca_user, it's better to use functions instead of
staticmethods, unless you'll want to override them in subclasses (which
you're explicitly discouraging here, by using the double underscore).
Anyway I don't get why you want these to be staticmethods.
(Note to self: I'm at line 1866 of the patch)
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
On 7/14/2014 4:45 AM, Ade Lee wrote: Hi all, I have rebased all the previous patches against master, and have squashed them all into a single patch. Its a large patch, but as many folks have already reviewed the constituent precursor patches, most if it should be familiar and easier to review. The main difference with what was specified before is that the DRM database is installed as a subtree to o=ipaca. This means that no new replication agreements will be needed to replicate DRM data. Replication agreements set up for the Dogtag CA will automatically replicate DRM data. In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed - with specific changes to allow the ability to install a database as a subtree of an existing tree. At this time, these changes have not yet been checked into the dogtag source. You can obtain such a build from: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/ Please review, Thanks, Ade Some comments/questions: 1. The suffix for the DRM is o=ipadrm,o=ipaca. It's probably better to change it to ou=drm,o=ipaca since another ipa under o=ipaca would be redundant. In the future we might want to migrate the current CA entries into ou=ca,o=ipaca subtree so that ou=ca and ou=drm will be at the same level, and keep o=ipaca as the parent tree for Dogtag subsystems. Alternatively, we probably could merge o=ipaca and o=ipadrm since the structure of each tree seems to have been designed to share the user and groups, but still maintain separate structure for CA/KRA-specific storage. The current Dogtag probably doesn't support this, but it's a possibility with additional works. 2. If a clone doesn't have DRM installed but it's getting replicated DRM data, is there any concern? 3. The Dogtag dependency should be updated to 10.2. Also the dogtag_version and DOGTAG_VERSION variables are probably not granular enough to detect the minor version. This message should be updated too: Dogtag must be version 10.1 or above to install DRM 4. It's probably unnecessary to override the following methods in CAInstance since they only call the base methods. * enable() * start_instance() * stop_instance() * restart_instance() * http_proxy() 5. The following code in ipaserver/plugins/dogtag.py will no longer work due to a recent change in Dogtag: transport_cert = kraclient.system_certs.get_transport_cert() tcert = transport_cert[ len(pki.CERT_HEADER): len(transport_cert) - len(pki.CERT_FOOTER)] crypto.import_cert( self.transport_nick, base64.decodestring(tcert), u,u,u) This is how it's used now in drmtest.py: transport_cert = kraclient.system_certs.get_transport_cert() print Subject DN: + transport_cert.subject_dn print transport_cert.encoded crypto.import_cert(transport_nick, transport_cert, u,u,u) 6. The code in ipaserver/install/drminstance.py creates a file /tmp/drm.p12. How long will this file stay in the /tmp folder? Should it be moved into a more permanent location? If it's a temporary file, can we use the python tempfile module? -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for DNSSEC keys
On 24.6.2014 08:43, Jan Cholasta wrote: On 20.6.2014 20:23, Simo Sorce wrote: On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote: ipk11Private;privatekey: TRUE ipk11Private;publickey: FALSE can these two ever hold a different value ? ie a privatekey be FALSE and a publickey be TRUE ? If not I suggest you do not add this attribute at all and assume their value ? +1, we can use default values for most, if not all of the boolean flag attributes. Personally, I would try to avoid using ipk11 attributes until the PKCS#11 module is designed/implemented. I hope that this will not create headache in future... Anyway, I have taken default values used by OpenDNSSEC v1 and modified them a little bit to accommodate our requirements. I'm using [1] as reference. Public keys === CKA_CLASS CKO_PUBLIC_KEY CKA_COPYABLETRUE CKA_DERIVE FALSE CKA_ENCRYPT FALSE CKA_LOCAL TRUE CKA_MODIFIABLE TRUE CKA_PRIVATE TRUE CKA_TRUSTED FALSE CKA_VERIFY TRUE CKA_VERIFY_RECOVER TRUE CKA_WRAPFALSE Private keys CKA_CLASS CKO_PRIVATE_KEY CKA_ALWAYS_AUTHENTICATE FALSE CKA_ALWAYS_SENSITIVETRUE CKA_COPYABLETRUE CKA_DECRYPT FALSE CKA_DERIVE FALSE CKA_EXTRACTABLE TRUE # changed by pspacek CKA_LOCAL TRUE CKA_MODIFIABLE TRUE CKA_NEVER_EXTRACTABLE TRUE CKA_PRIVATE TRUE CKA_SENSITIVE TRUE CKA_SIGNTRUE CKA_SIGN_RECOVERTRUE CKA_UNWRAP FALSE CKA_WRAP_WITH_TRUSTED FALSE We can use this set for all DNSSEC key pair objects. Replica keys will require small change, i.e. to change SIGN/VERIFY attributes to FALSE and WRAP/UNWRAP attributes to TRUE. OpenDNSSEC itself doesn't create any secret keys so we have to invent own defaults. I propose to use following values: Secret keys === CKA_CLASS CKO_SECRET_KEY CKA_COPYABLETRUE CKA_DECRYPT FALSE CKA_DERIVE FALSE CKA_ENCRYPT FALSE CKA_EXTRACTABLE TRUE CKA_MODIFIABLE TRUE CKA_PRIVATE TRUE CKA_SENSITIVE FALSE CKA_SIGNFALSE CKA_UNWRAP TRUE CKA_VERIFY FALSE CKA_WRAPTRUE CKA_WRAP_WITH_TRUSTED FALSE (btw I forgot what's the point of that attribute) When it is true, a user may not access the object until the user has been authenticated to the token (what PKCS#11 spec says). In practice it means that SoftHSM encrypts values of PRIVATE objects before storing them to file system. [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] OTP Replay Prevention Review
http://www.freeipa.org/page/V4/OTPReplayPrevention The above link contains the design page for our OTP Replay Prevention countermeasures proposal in FreeIPA. Please review. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix typos in dns.py
On Tue, 2014-07-15 at 21:49 -0600, Gabe Alford wrote: Hello, Fixes https://fedorahosted.org/freeipa/ticket/4429 ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
