Re: [Freeipa-devel] LDAP schema for DNSSEC keys
On 16.7.2014 17:13, Petr Spacek wrote: 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_CLASSCKO_PUBLIC_KEY CKA_COPYABLETRUE CKA_DERIVEFALSE CKA_ENCRYPTFALSE CKA_LOCALTRUE CKA_MODIFIABLETRUE CKA_PRIVATETRUE CKA_TRUSTEDFALSE CKA_VERIFYTRUE CKA_VERIFY_RECOVERTRUE CKA_WRAPFALSE Private keys CKA_CLASSCKO_PRIVATE_KEY CKA_ALWAYS_AUTHENTICATEFALSE CKA_ALWAYS_SENSITIVETRUE CKA_COPYABLETRUE CKA_DECRYPTFALSE CKA_DERIVEFALSE CKA_EXTRACTABLETRUE # changed by pspacek CKA_LOCALTRUE CKA_MODIFIABLETRUE CKA_NEVER_EXTRACTABLETRUE CKA_PRIVATETRUE CKA_SENSITIVETRUE CKA_SIGNTRUE CKA_SIGN_RECOVERTRUE CKA_UNWRAPFALSE CKA_WRAP_WITH_TRUSTEDFALSE If you want the keys to be extractable, you also need to set CKA_SENSITIVE (and CKA_ALWAYS_SENSITIVE) to CK_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. Replica private keys should not be extractable, i.e. should have CKA_EXTRACTABLE = CK_FALSE and CKA_SENSITIVE = CK_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_CLASSCKO_SECRET_KEY CKA_COPYABLETRUE CKA_DECRYPTFALSE CKA_DERIVEFALSE CKA_ENCRYPTFALSE CKA_EXTRACTABLETRUE CKA_MODIFIABLETRUE CKA_PRIVATETRUE CKA_SENSITIVEFALSE CKA_SIGNFALSE CKA_UNWRAPTRUE CKA_VERIFYFALSE CKA_WRAPTRUE CKA_WRAP_WITH_TRUSTEDFALSE When master key is rotated, CKA_WRAP on the old key should be set to CK_FALSE, so that new DNSSEC keys can't be wrapped with it. (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 BTW I have noticed at https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm that public key of each replica is stored in a ipk11 entry under cn=DNS. IMO it should be enough to store just the public key blob in ipaPublicKey attribute in cn=DNS itself. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0244] ipatests: test_trust: Add test to cover lookup of trusdomains
Hi,
Adds an integration tests that checks that all trustdomains are
able to be found by trustdomain-find command right after the
trust has been established.
Also moves some code to allow easier adding common test cases for
both POSIX and non-POSIX test classes.
https://fedorahosted.org/freeipa/ticket/4208
--
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From b8c8d93c90afffd68b546f05960b1d2480a8c90e Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Mon, 16 Jun 2014 17:25:04 +0200
Subject: [PATCH] ipatests: test_trust: Add test to cover lookup of trusdomains
Adds an integration tests that checks that all trustdomains are
able to be found by trustdomain-find command right after the
trust has been established.
Also moves some code to allow easier adding common test cases for
both POSIX and non-POSIX test classes.
https://fedorahosted.org/freeipa/ticket/4208
---
ipatests/test_integration/test_trust.py | 36 -
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/ipatests/test_integration/test_trust.py b/ipatests/test_integration/test_trust.py
index 95e48dd9c38df24e861f8f78857682899fa7fe30..597f4ced73cb9a04c89e05b04d647c4be83c0e3b 100644
--- a/ipatests/test_integration/test_trust.py
+++ b/ipatests/test_integration/test_trust.py
@@ -17,6 +17,7 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see http://www.gnu.org/licenses/.
+import nose
import re
from ipatests.test_integration.base import IntegrationTest
@@ -29,6 +30,7 @@ class ADTrustBase(IntegrationTest):
topology = 'line'
num_ad_domains = 1
+optional_extra_roles = ['ad_subdomain']
@classmethod
def install(cls):
@@ -38,6 +40,14 @@ class ADTrustBase(IntegrationTest):
cls.check_sid_generation()
cls.configure_dns_and_time()
+# Determine whether the subdomain AD is available
+try:
+child_ad = cls.host_by_role(cls.optional_extra_roles[0])
+cls.ad_subdomain = '.'.join(
+ child_ad.hostname.split('.')[1:])
+except LookupError:
+cls.ad_subdomain = None
+
@classmethod
def install_adtrust(cls):
Test adtrust support installation
@@ -64,16 +74,32 @@ class ADTrustBase(IntegrationTest):
tasks.configure_dns_for_trust(cls.master, cls.ad)
tasks.sync_time(cls.master, cls.ad)
-
-class TestBasicADTrust(ADTrustBase):
-Basic Integration test for Active Directory
-
def test_establish_trust(self):
Tests establishing trust with Active Directory
tasks.establish_trust_with_ad(self.master, self.ad,
extra_args=['--range-type', 'ipa-ad-trust'])
+def test_all_trustdomains_found(self):
+
+Tests that all trustdomains can be found.
+
+
+if self.ad_subdomain is None:
+raise nose.SkipTest('AD subdomain is not available.')
+
+result = self.master.run_command(['ipa',
+ 'trustdomain-find',
+ self.ad.domain.name])
+
+# Check that both trustdomains appear in the result
+assert self.ad.domain.name in result.stdout_text
+assert self.ad_subdomain in result.stdout_text
+
+
+class TestBasicADTrust(ADTrustBase):
+Basic Integration test for Active Directory
+
def test_range_properties_in_nonposix_trust(self):
Check the properties of the created range
@@ -111,7 +137,7 @@ class TestBasicADTrust(ADTrustBase):
class TestPosixADTrust(ADTrustBase):
Integration test for Active Directory with POSIX support
-def test_establish_trust_with_posix_attributes(self):
+def test_establish_trust(self):
# Not specifying the --range-type directly, it should be detected
tasks.establish_trust_with_ad(self.master, self.ad)
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0244] ipatests: test_trust: Add test to cover lookup of trusdomains
On 07/17/2014 01:20 PM, Tomas Babej wrote:
Hi,
Adds an integration tests that checks that all trustdomains are
able to be found by trustdomain-find command right after the
trust has been established.
Also moves some code to allow easier adding common test cases for
both POSIX and non-POSIX test classes.
https://fedorahosted.org/freeipa/ticket/4208
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Also, attached is a required patch for freeipa-ci.
--
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 77e88d4896b694a9f22f0e25063fd2b636859989 Mon Sep 17 00:00:00 2001
From: Tomas Babej tomasba...@gmail.com
Date: Thu, 10 Jul 2014 10:41:08 +0200
Subject: [PATCH] Enable subdomains for basic trust tests
---
jenkins-job-builder/freeipa-jobs.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/jenkins-job-builder/freeipa-jobs.yaml b/jenkins-job-builder/freeipa-jobs.yaml
index 710187f6b31fbe8a79f2b126a03c446a79e8b4e4..38734a1ded83df1f08092b7af9a0b1e08e4f9750 100644
--- a/jenkins-job-builder/freeipa-jobs.yaml
+++ b/jenkins-job-builder/freeipa-jobs.yaml
@@ -485,8 +485,10 @@
name: ipa.test
type: TRUST_IPA
- hosts:
- - name: ad
+ - name: ad.ad.test
role: ad
+ - name: child.child.ad.test
+role: ad_subdomain
name: ad.test
type: AD
- '{prefix}-integration-{os}-{pretty_name}':
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Enable debug pid in smb.conf
On 07/16/2014 05:48 AM, Gabe Alford wrote: Hello, Adds debug pid = yes to smb.conf when ipa-adtrust-install command is run. https://fedorahosted.org/freeipa/ticket/3485 Thanks, Gabe ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Thanks, ACK. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Correct firewall ports for multi-master replicas
On 07/14/2014 10:20 AM, Petr Spacek wrote: On 12.7.2014 08:40, James wrote: Hi freeipa-devel, I just added automatic firewalling for puppet-ipa. (Disclaimer it's currently untested...) What I'm missing is an exact and exhaustive list of exactly which ports each replica needs open for each other replica. I'm hoping that this list is symmetrical. AFAIK ipa-replica-conncheck utility and ipa-server-install script should show list of required ports. The ipa-replica-conncheck list is a good start, but it does not for example show ports of optional services, like DNS. You need to figure these out based on installed optional services. Martin ___ 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/16/2014 02:55 PM, Petr Viktorin wrote:
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.
Also, in e.g.
root_logger.debug(
'Unable to determine PIN for the Dogtag instance: %s' % str(e))
the s in %s means convert to string, so explicit str() isn't
necessary.
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,
)
Same in DogtagInstance, DRMInstance.
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.
dogtaginstance.py, drminstance.py: Avoid star imports, especially in new
code. AFAICS you're only using root_logger from ipapython.ipa_log_manager.
Also consider using an class-specific logger:
class DogtagInstance(...):
def __init__(...):
...
self.log = ipa_log_manager.log_mgr.get_logger(self)
later:
[Freeipa-devel] weird data interaction
Saw something very weird today but my setup was also a bit odd so it may not be worthy of a ticket. Need a second opinion. Ok, so I wanted to test Jan's CA patches. They don't apply to current master due to the churn pre-4.0, so I just rewound the world to July 3 and applied them on the master branch. I don't believe the issues I'm seeing are related to his patches in any way. My environment is two masters, F-20, reasonably updated. Ok, so I started with them with 3.3.5 installs as I wanted to test upgrades. As a goof I ran the ipatests on one of them to simulate a bunch of work. There were some failures but I didn't pay close attention because testing in a replicated environment is a bit of an unknown (there are some timing issues IIRC). Anyway, so then I updated one of the masters to this pre-4.0 CA-patches build. Then I re-ran the tests. These I took more notice of as about half of them failed. Most of them related to adding users and this is due to the user objectclasses test we have. It can't revert a change: On the 4.0-ish master: # ipa config-mod --delattr ipauserobjectclasses=ipahost ipa: ERROR: change collided with another change Ouch. With ipahost in there nothing really adds correctly: # ipa user-add --first=tim --last=user testuser2 ipa: ERROR: missing attribute fqdn required by object class ipaHost On the 3.3.5 server I get a different, ACI-related error: # ipa user-add --first=tim --last=user testuser ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'member' attribute of entry 'cn=ipausers,cn=groups,cn=accounts,dc=greyoak,dc=com'. The user is actually added, just not to the ipausers group. And how, might you ask, did it get added at all? The config entry is out-of-sync between the masters: 3.3.5: Default user objectclasses: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser 4.0.0: Default user objectclasses: ipahost, ipaobject, person, top, ipasshuser, inetorgperson, organizationalperson, krbticketpolicyaux, krbprincipalaux, inetuser, posixaccount So yeah, I've got a bit of a Frankenstein install going on here, but has anyone else seen anything remotely similar? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] webui: 696 support wildcard attribute level rights
On 7/10/2014 7:23 AM, Petr Vobornik wrote:
Reproduction:
* add 'extensibleObject' object class to target object
https://fedorahosted.org/freeipa/ticket/4380
This is the original if-condition:
(!rights
!(that.flags.indexOf('w_if_no_aci') -1
write_oc))
|| (rights rights.indexOf('w') 0)
Here if 'rights' has a value but there's no 'w' in it, the expression
will evaluate to true.
This is the new code:
!can_write
!rights
!(that.flags.indexOf('w_if_no_aci') -1 write_oc)
Here if 'rights' has any value the expression will evaluate to false. Is
this correct?
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 697-702 webui: usability improvements in attribute widget
On 7/10/2014 8:02 AM, Petr Vobornik wrote: ACK. Comments below: == [PATCH] 699 webui: optimize (re)creation of option widget == There is a case where attributes widget can contain 1000 items. It's about 3000 nodes. It's slow in jQuery. Simple move to dojo speeds it up (is closer to native calls) while maintaining developer friendliness. Now the biggest lag is in browser's render. It's probably not worth developer time to optimize that. Is it common to have many items in this widget (doesn't have to be bigger than 1000, but just large enough)? Maybe the UI should provide some kind of paging interface, not just for performance reason, but also for usability. == [PATCH] 700 webui: custom attr in attributes widget == Web UI doesn't always know what are the possible attributes for target object. This will allow to add custom attributes if necessary. Right now you can add an undefined attribute, but it will fail when you try to save it. Should the UI perform a schema validation before accepting the new attribute? Or should the UI provide a list of valid attributes? -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 703-707 webui: improvements in permission details page
ACK. See comment below: On 7/10/2014 7:38 AM, Petr Vobornik wrote: == [PATCH] 707 webui: disable ipapermbindruletype if permission in a privilege == User is not able to change Bind Rule Type if permission is already member of a privilege. Let's disable it and don't confuse user. If you open a permission, go to the Privileges tab, add/remove a privilege, then go back to the Settings tab, the Bind rule type is not updated automatically, you'd have to click Refresh to see the change. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 708 webui: fix disabled state of service's PAC type
On 7/10/2014 7:38 AM, Petr Vobornik wrote: Nested options (MS-PAC and PAD) of service's PAC type should be disabled if no value is supplied (default value is Inherited from server configuration). That was not the case - regression. This patch fixes it and along with it simplifies the update method of option_widget_base to be more comprehensible. ACK. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
