Re: [Freeipa-devel] [PATCH 0060] Fix ipa-getkeytab for pre-4.0 servers
On 07/24/2014 05:12 PM, Nathaniel McCallum wrote: On Thu, 2014-07-24 at 17:19 +0300, Alexander Bokovoy wrote: On Thu, 24 Jul 2014, Nathaniel McCallum wrote: Also, make the error messages for this fallback case less scary and clean up some indentation issues in the nearby code which made this code difficult to read. ACK. Here is how it looks now in /var/log/ipaclient-install.log: 2014-07-24T14:15:36Z DEBUG Starting external process 2014-07-24T14:15:36Z DEBUG args='/usr/sbin/ipa-join' '-s' 'ipa-07-f20.t.vda.li' '-b' 'dc=t,dc=vda,dc=li' '-h' 'ipa-01.t.vda.li' 2014-07-24T14:15:38Z DEBUG Process finished, return code=0 2014-07-24T14:15:38Z DEBUG stdout= 2014-07-24T14:15:38Z DEBUG stderr=Failed to parse result: unsupported extended operation Retrying with pre-4.0 keytab retrieval method... Keytab successfully retrieved and stored in: /etc/krb5.keytab Certificate subject base is: O=T.VDA.LI 2014-07-24T14:15:38Z INFO Enrolled in IPA realm T.VDA.LI Attached is the same patch with the bug link in the commit message. Good! Thanks for fixing the scary error messages :-) Pushed to: master: 96986056f65beb120cd74a311524b6601383ee80 ipa-4-1: 96986056f65beb120cd74a311524b6601383ee80 ipa-4-0: 217aba77dcfc59c52ad565e33af341da06e76bcc Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 478 Allow hashed passwords in DS
On Wed, 23 Jul 2014, Martin Kosek wrote: See related thread #4450: how to allow password migration? for more information. --- Without nsslapd-allow-hashed-passwords being turned on, user password migration fails. https://fedorahosted.org/freeipa/ticket/4450 ACK, also given that Bryce reported it working for his environment. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] ipa-replica-manage and topology plugin
On Fri, 2014-07-25 at 10:13 +0200, Ludwig Krispenz wrote: Hi, I am working on ticket #4302 and am building a protoptype to verify if the current design [1] will work an what is missing. Now the question comes up, how will this be managed and what happens with eg ipa-replica-manage ? If the topology plugin is deployed and configured it will control all replication related tasks via modifcations of the entries in the shared tree, direct modofications of replication agreements will be rejected. This makes several subcommands of ipa-replica-manage unusable, like connect/disconnect/... . So should the functionality of ipa-replica-manage be changed to use the shared tree or should there be a new command like ipa-topology-manage. I would prefere a new command, so ipa-replica-manage is there if the topology plugin is disabled, also there shoul be some new subcommands like topology-verify, topology-view ... Let me know what you think, I think the current mechanism of *managing* the topology works well, what I'd like to understand is what will change functionality wise with this feature... For some background, I have written the code (but not yet blogged or well documented) how topologies can be managed and defined in puppet... You might be interested in: https://github.com/purpleidea/puppet-ipa/commit/b621b1ae2d33ac2f56874fd7948f45829c6047d7 and https://github.com/purpleidea/puppet-ipa/commit/73712d1b051398c4193b081c3f35eddf679896e2 I define the topology shape algorithmic-ally (eg: ring, flat, star, etc...) and the replica make it happen :) Cheers, James Thanks, Ludwig [1] http://www.freeipa.org/page/V4/Manage_replication_topology ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 478 Allow hashed passwords in DS
On 07/25/2014 10:26 AM, Alexander Bokovoy wrote: On Wed, 23 Jul 2014, Martin Kosek wrote: See related thread #4450: how to allow password migration? for more information. --- Without nsslapd-allow-hashed-passwords being turned on, user password migration fails. https://fedorahosted.org/freeipa/ticket/4450 ACK, also given that Bryce reported it working for his environment. Pushed to: master: 15eb343b9c235a1ca3a6cc48f730590949d439ec ipa-4-1: 15eb343b9c235a1ca3a6cc48f730590949d439ec ipa-4-0: 47825306169b941902a443b01ac5a51991dcfb95 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0057] Add TOTP watermark support
On 07/25/2014 10:24 AM, Alexander Bokovoy wrote: On Fri, 11 Jul 2014, Nathaniel McCallum wrote: This prevents the reuse of TOTP tokens by recording the last token interval that was used. This will be replicated as normal. However, this patch does not increase the number of writes to the database in the standard authentication case. This is because it also eliminates an unnecessary write during authentication. Hence, this patch should be write-load neutral with the existing code. Further performance enhancement is desired, but is outside the scope of this patch. https://fedorahosted.org/freeipa/ticket/4410 ACK. I've tested it with successive LDAP binds with TOTP token and only first attempt to bind was successful with the same TOTP code. Thanks! Pushed to: master: d3638438fce1a9d1e07c2be3b8f43befb07a6b40 ipa-4-1: d3638438fce1a9d1e07c2be3b8f43befb07a6b40 ipa-4-0: b7c0c9335a5a0f88243b63bb26d6349444e6ed19 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Releasing FreeIPA 4.0.1
Hello, As I mentioned earlier, I would like to very soon release FreeIPA 4.0.1 containing the first bunch of stabilization fixes in 4.0 branch. One of the most critical ones were client installation and migration issues which blocked some of our users. Those are now fixed. This is the candidate release notes, updates or feedback welcome: http://www.freeipa.org/page/Releases/4.0.1 Is there anything else you would see as a blocker for release? I plan to move all remaining 4.0.1 Trac milestone tickets to new 4.0.2 milestone which would be released in August. The only think I am now little concerned about is following report for new 389 DS: https://admin.fedoraproject.org/updates/FEDORA-2014-8709/389-ds-base-1.3.2.20-1.fc20 I can now also see it in my single node server, I am not sure whether it is benign (and annoying) error message or something more serious? Ludwig, is this something that should stall the FreeIPA release? After all, freeipa-server depends on this DS version. -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 716 baseldap: return 'none' attr level right as unicode string
Returning non-unicode causes serialization into base64 which causes havoc in Web UI. https://fedorahosted.org/freeipa/ticket/4454 IMHO we should fix JSON-RPC serialization to encode non-unicode strings to normal JSON strings. -- Petr Vobornik From 1158e43ad6fd9107390f14a00b95c61ce489ff20 Mon Sep 17 00:00:00 2001 From: Petr Vobornik pvobo...@redhat.com Date: Fri, 25 Jul 2014 12:39:48 +0200 Subject: [PATCH] baseldap: return 'none' attr level right as unicode string Returning non-unicode causes serialization into base64 which causes havoc in Web UI. https://fedorahosted.org/freeipa/ticket/4454 --- ipalib/plugins/baseldap.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py index 610b9b0f11660996a874fe6151e202f8241c5f27..865a357bb45e897e9459adbadfd6e72a939d0706 100644 --- a/ipalib/plugins/baseldap.py +++ b/ipalib/plugins/baseldap.py @@ -213,7 +213,7 @@ def get_effective_rights(ldap, dn, attrs=None): if v == 'none': # the string none means no rights found # see https://fedorahosted.org/freeipa/ticket/4359 -v = '' +v = u'' rdict[k.strip().lower()] = v return rdict -- 1.9.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Releasing FreeIPA 4.0.1
On 07/25/2014 12:23 PM, Martin Kosek wrote: Hello, As I mentioned earlier, I would like to very soon release FreeIPA 4.0.1 containing the first bunch of stabilization fixes in 4.0 branch. One of the most critical ones were client installation and migration issues which blocked some of our users. Those are now fixed. This is the candidate release notes, updates or feedback welcome: http://www.freeipa.org/page/Releases/4.0.1 Is there anything else you would see as a blocker for release? I plan to move all remaining 4.0.1 Trac milestone tickets to new 4.0.2 milestone which would be released in August. The only think I am now little concerned about is following report for new 389 DS: https://admin.fedoraproject.org/updates/FEDORA-2014-8709/389-ds-base-1.3.2.20-1.fc20 I can now also see it in my single node server, I am not sure whether it is benign (and annoying) error message or something more serious? Ludwig, is this something that should stall the FreeIPA release? After all, freeipa-server depends on this DS version. This message is caused by fix for #47834, it tries to get the connid (for use in potential error messages later) and this fails for internal operations, it checks this case, but the error message is already logged :-( I think you should see this for any internal add/delete/modrdn operation. It shouldn't cause any problems, but could be very annoying - so it should be fixed. If it should hold 4.0.1 or can wait for 4.0.2 is your decision. Cant we upgrade DS independently of upgrading to 4.0.2, just when it is available ? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Releasing FreeIPA 4.0.1
On Fri, 25 Jul 2014, Ludwig Krispenz wrote: On 07/25/2014 12:23 PM, Martin Kosek wrote: Hello, As I mentioned earlier, I would like to very soon release FreeIPA 4.0.1 containing the first bunch of stabilization fixes in 4.0 branch. One of the most critical ones were client installation and migration issues which blocked some of our users. Those are now fixed. This is the candidate release notes, updates or feedback welcome: http://www.freeipa.org/page/Releases/4.0.1 Is there anything else you would see as a blocker for release? I plan to move all remaining 4.0.1 Trac milestone tickets to new 4.0.2 milestone which would be released in August. The only think I am now little concerned about is following report for new 389 DS: https://admin.fedoraproject.org/updates/FEDORA-2014-8709/389-ds-base-1.3.2.20-1.fc20 I can now also see it in my single node server, I am not sure whether it is benign (and annoying) error message or something more serious? Ludwig, is this something that should stall the FreeIPA release? After all, freeipa-server depends on this DS version. This message is caused by fix for #47834, it tries to get the connid (for use in potential error messages later) and this fails for internal operations, it checks this case, but the error message is already logged :-( I think you should see this for any internal add/delete/modrdn operation. It shouldn't cause any problems, but could be very annoying - so it should be fixed. If it should hold 4.0.1 or can wait for 4.0.2 is your decision. Cant we upgrade DS independently of upgrading to 4.0.2, just when it is available ? We can upgrade 389-ds independently. Put a warning into FreeIPA 4.0.1 release notes, explaining the message being harmless and fix 389-ds asynchronously in Fedora. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] ipa-replica-manage and topology plugin
On 07/25/2014 10:29 AM, James wrote: On Fri, 2014-07-25 at 10:13 +0200, Ludwig Krispenz wrote: Hi, I am working on ticket #4302 and am building a protoptype to verify if the current design [1] will work an what is missing. Now the question comes up, how will this be managed and what happens with eg ipa-replica-manage ? If the topology plugin is deployed and configured it will control all replication related tasks via modifcations of the entries in the shared tree, direct modofications of replication agreements will be rejected. This makes several subcommands of ipa-replica-manage unusable, like connect/disconnect/... . So should the functionality of ipa-replica-manage be changed to use the shared tree or should there be a new command like ipa-topology-manage. I would prefere a new command, so ipa-replica-manage is there if the topology plugin is disabled, also there shoul be some new subcommands like topology-verify, topology-view ... Let me know what you think, I think the current mechanism of *managing* the topology works well, what I'd like to understand is what will change functionality wise with this feature... the major change is that with this plugin replication information will be in the shared tree and so everything is available on any server and can be changed on any server, no creation of individual repl agreements need to be setup. what ipa-replica-manage connect does would be achieved, by adding a segment to the topology tree, this would be replicated and on each affected endpoint, the plugin would create the agreement For some background, I have written the code (but not yet blogged or well documented) how topologies can be managed and defined in puppet... You might be interested in: https://github.com/purpleidea/puppet-ipa/commit/b621b1ae2d33ac2f56874fd7948f45829c6047d7 and https://github.com/purpleidea/puppet-ipa/commit/73712d1b051398c4193b081c3f35eddf679896e2 I define the topology shape algorithmic-ally (eg: ring, flat, star, etc...) and the replica make it happen :) I will look into this, but after a first quick look it turnes out that ipa-replica-manage is already used in other applications, not only by admins on the command line, so probably the changes should be inside ipa-replica-manage and transparent to other apps. Cheers, James Thanks, Ludwig [1] http://www.freeipa.org/page/V4/Manage_replication_topology ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 716 baseldap: return 'none' attr level right as unicode string
On 25.7.2014 13:02, Alexander Bokovoy wrote: On Fri, 25 Jul 2014, Petr Vobornik wrote: Returning non-unicode causes serialization into base64 which causes havoc in Web UI. https://fedorahosted.org/freeipa/ticket/4454 ACK for this patch. Pushed to: master: c475c093c9524353be0fbc1d5690a081b0c56cdc ipa-4-1: c475c093c9524353be0fbc1d5690a081b0c56cdc ipa-4-0: a356385f2d73d17ec883d2618d6037efee08f548 IMHO we should fix JSON-RPC serialization to encode non-unicode strings to normal JSON strings. We should use unicode strings everywhere and leave non-unicode ones to present binary content, that's why it is encoded as base64. So no, we shouldn't change JSON-RPC serialization. However, we need to find a way to track non-unicode strings where possible. ok -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Releasing FreeIPA 4.0.1
On 07/25/2014 01:19 PM, Alexander Bokovoy wrote: On Fri, 25 Jul 2014, Ludwig Krispenz wrote: On 07/25/2014 12:23 PM, Martin Kosek wrote: Hello, As I mentioned earlier, I would like to very soon release FreeIPA 4.0.1 containing the first bunch of stabilization fixes in 4.0 branch. One of the most critical ones were client installation and migration issues which blocked some of our users. Those are now fixed. This is the candidate release notes, updates or feedback welcome: http://www.freeipa.org/page/Releases/4.0.1 Is there anything else you would see as a blocker for release? I plan to move all remaining 4.0.1 Trac milestone tickets to new 4.0.2 milestone which would be released in August. The only think I am now little concerned about is following report for new 389 DS: https://admin.fedoraproject.org/updates/FEDORA-2014-8709/389-ds-base-1.3.2.20-1.fc20 I can now also see it in my single node server, I am not sure whether it is benign (and annoying) error message or something more serious? Ludwig, is this something that should stall the FreeIPA release? After all, freeipa-server depends on this DS version. This message is caused by fix for #47834, it tries to get the connid (for use in potential error messages later) and this fails for internal operations, it checks this case, but the error message is already logged :-( I think you should see this for any internal add/delete/modrdn operation. It shouldn't cause any problems, but could be very annoying - so it should be fixed. If it should hold 4.0.1 or can wait for 4.0.2 is your decision. Cant we upgrade DS independently of upgrading to 4.0.2, just when it is available ? We can upgrade 389-ds independently. Put a warning into FreeIPA 4.0.1 release notes, explaining the message being harmless and fix 389-ds asynchronously in Fedora. ACK. I added a Known Issue paragraph to release notes: http://www.freeipa.org/page/Releases/4.0.1#Excessive_logging_by_389-ds-base_1.3.2.20 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] ipa-replica-manage and topology plugin
Ludwig Krispenz wrote: Hi, I am working on ticket #4302 and am building a protoptype to verify if the current design [1] will work an what is missing. Now the question comes up, how will this be managed and what happens with eg ipa-replica-manage ? If the topology plugin is deployed and configured it will control all replication related tasks via modifcations of the entries in the shared tree, direct modofications of replication agreements will be rejected. This makes several subcommands of ipa-replica-manage unusable, like connect/disconnect/... . So should the functionality of ipa-replica-manage be changed to use the shared tree or should there be a new command like ipa-topology-manage. I would prefere a new command, so ipa-replica-manage is there if the topology plugin is disabled, also there shoul be some new subcommands like topology-verify, topology-view ... Let me know what you think, Thanks, Ludwig [1] http://www.freeipa.org/page/V4/Manage_replication_topology It occurs to me this could make for a bumpy transition. It would mean that an older master can't manage the topology of a new master since ipa-replica-manage on that old master is going to try to make direct changes. So I suppose we need at least good error messages and documentation. Given that when it comes to upgrading we recommending doing it fairly quickly. We can add to that that recommendation any topology management should be done from the newest master. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Announcing FreeIPA 4.0.1
The FreeIPA team is proud to announce FreeIPA v4.0.1! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds are available for Fedora 21 or in an unofficial Fedora 20 [https://copr.fedoraproject.org/coprs/pviktori/freeipa/ COPR repository]. These release notes can be read at: http://www.freeipa.org/page/Releases/4.0.1 == Highlights in 4.0.1 == === Enhancements === * TOTP watermark support was added. The last token interval is now being added to database and replicated in FreeIPA realm. Note that the number of writes is kept the same as an unnecessary LDAP write was eliminated. * Effective Attributes widget in the Add Permission Web UI page was improved === Bug fixes === * ipa-client-install is now again able to join older servers (pre-4.0) * Password migration in migrate-ds command was fixed by enabling nsslapd-allow-hashed-passwords setting by default * ipa-client-install no longer crashes during uninstallation when chronyd service cannot be started * Server installation could hang as no members could be added to cn=adtrust agents system account * Web UI login page now distinguishes between OTP users with invalid and expired password and properly shows the Reset password dialog * ipa-server-install and ipa-replica-install now better detects when PKI was configured and is able to properly uninstall it when installation crashed == Known Issues == === Excessive logging by 389-ds-base 1.3.2.20 === FreeIPA 4.0.1 pulls 389-ds-base 1.3.2.20 as a dependency ([https://admin.fedoraproject.org/updates/FEDORA-2014-8709/389-ds-base-1.3.2.20-1.fc20 updates-testing repo] in Fedora 20). However, this version of the Directory Server produces following logs for internal write operations: [26/Jul/2014:01:28:53 +0200] - Connection is NULL and hence cannot access SLAPI_CONN_ID This log is [http://www.redhat.com/archives/freeipa-devel/2014-July/msg00388.html benign], Directory Server team tracks the problem in ticket [https://fedorahosted.org/389/ticket/47834 #47834]. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-upgradeconfig # ipa-ldap-updater --upgrade Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.0 == === David Kupka (2) === * Fix ipa-client-install --uninstall crash * Always record that pkicreate has been executed. === Gabe (2) === * Fix typos in dns.py * Enable debug pid in smb.conf === Lukáš Slebodník (2) === * Fix warning: Using uninitialized value ld. * Add missing break === Martin Košek (2) === * Allow hashed passwords in DS * Become IPA 4.0.1 === Nathaniel McCallum (4) === * Fix login password expiration detection with OTP * Update freeipa-server krb5-server dependency to 1.11.5-5 * Fix ipa-getkeytab for pre-4.0 servers * Add TOTP watermark support === Petr Viktorin (3) === * baseldap: Return empty string when no effective rights are found * ldap2 indirect membership processing: Use global limits if greater than per-query ones * test_xmlrpc: Update tests === Petr Voborník (14) === * webui: capitalize labels of undo and undo all buttons * webui: improve usability of attributes widget * webui: add filter to attributes widget * webui: optimize (re)creation of option widget * webui: custom attr in attributes widget * webui: attr widget: get list of possible attrs from ipapermdefaultattr * webui: option_widget_base: sort options * webui: reflect readonly state * webui: fix add of input group class * webui: show managed fields as readonly and not disabled * webui: fix selection of empty value in a select widget * webui: disable ipapermbindruletype if
Re: [Freeipa-devel] LDAP schema for DNSSEC keys
On 17.7.2014 10:30, Jan Cholasta wrote: 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. I have updated design page and diagrams: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#LDAPschema -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC key metadata handling
On 18.6.2014 19:19, Petr Spacek wrote: On 13.6.2014 18:43, Petr Spacek wrote: On 12.6.2014 17:49, Petr Spacek wrote: On 12.6.2014 17:19, Simo Sorce wrote: On Thu, 2014-06-12 at 17:08 +0200, Petr Spacek wrote: Hello list, I have realized that we need to store certain DNSSEC metadata for every (zone,key,replica) triplet. It is necessary to handle splits in replication topology. DNSSEC key can be in one of following states: - key created - published but not used for signing - published and used for signing - published and not used for signing but old signatures exist - unpublished Every state transition has to be postponed until relevant TTL expires, and of course, we need to consider TTL on all replicas. Example of a problem DNS TTL=10 units Key life time=100 units Replica=1 Key=1 Time=0 Published Replica=2 Key=1 Time=0 Published Replica=1 Key=1 Time=10 Published, signing Replica=2 Key=1 Time=10 Published, signing Replica=1 Key=2 Time=90 Generated, published, not signing yet Replica=2 Key=2 Time=90 replication is broken: key=2 is not on replica=2 Replica=1 Key=1 Time=100 ^^^ From time=100, all new signatures should be created with key=2 but that can break DNSSEC validation because key=2 is not available on replica=2. Can you explain how this break validation ? Aren't signatures regenerated on each replica ? They are. And so isn't each replica self-consistent ? Ah, sorry, I didn't mention one important detail. Keys published in the zone 'example.com.' have to match keys published in parent zone. There has to be a mechanism for synchronizing this. Validation will break if (keys published by parent) are not subset of (keys on replicas). Next logical step in the example above is to remove key1 from replica 1 so you will end replica1 having key2 and replica2 having only key1. How can we guarantee that synchronization mechanism will not wipe key1 from parent? Or the other way around? How can we guarantee that key2 was uploaded? Also, things will break is number of keys in parent exceeds reasonable number (because DNS replies will be to big etc.). Proposal 1 == - Store state and timestamps for (zone,key,replica) triplet - Do state transition only if all triplets (zone,key,?) indicate that all replicas reached desired state so the transition is safe. - This implicitly means that no transition will happen if one or more replicas is down. This is necessary otherwise DNSSEC validation can break mysteriously when keys got out of sync. dn: cn=some-replica-id,ipk11Label=zone1_keyid123_private, cn=keys, cn=sec, cn=dns, dc=example idnssecKeyCreated: timestamp idnssecKeyPublished: timestamp idnssecKeyActivated: timestamp idnssecKeyInactivated: timestamp idnssecKeyDeleted: timestamp Why do you care for all 5 states ? In short, to follow RFC 6781 and all it's requirements. Simo and I have discussed this off-line. The final decision is to rely on replication. The assumption is that if replication is broken, everything will break soon anyway, so the original proposal is overkill. We have to store one set of timestamps somewhere to be able to follow RFC 6781, so we decided to store it in the key-metadata object. I added other attributes to object class definition so it contains all necessary metadata. The new object class idnsSecKey is now complete. Please note that DN in the previous example was incorrect. It is necessary to store the metadata separately for pairs (zone, key) to cover the case where key is shared between zones. This also nicely splits metadata from actual key material. All attributes are single-valued. MUST attributes are: idnsSecKeyRef idnsSecKeyCreated idnsSecAlgorithm dn: cn=z/ksk+keytag, cn=keys, idnsname=example.com, cn=dns, dc=example objectClass: idnsSecKey idnsSecKeyRef: DN of the PKCS#11 key object under cn=keys, cn=sec, dn=dns idnsSecKeyCreated: timestamp idnsSecKeyPublish: timestamp idnsSecKeyActivate: timestamp idnsSecKeyInactive: timestamp idnsSecKeyDelete: timestamp idnsSecKeyZone: boolean equivalent to bit 7 (ZONE) in [1] idnsSecKeyRevoke: boolean equivalent to bit 8 (REVOKE) in [1] idnsSecKeySep: boolean equivalent to bit 15 (SEP) in [1] idnsSecAlgorithm: string used as mnemonic in [2] I haven't heard any complains so I allocated OIDs and I'm going to implement it. Relevant LDAP schema is: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#DNSSECmetadata Me and Honza have discussed off-line that reference from metadata to key material should be in form of PKCS#11 URI so it will work even with real HSM. The new definition is: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#idnsSecKeyRef -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] DNSSEC feature status (with pictures!)
Hello list, Now you have unique chance to stop me before I really implement something (:-), I'm leaving DNSSEC world for a while. I will resume work after two weeks of silence. Status == We (Martin Basti and me) have encountered various problems on our way to DNSSEC feature, you can read the summary: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#Implementation All necessary patches were submitted upstream. Now we need to really write IPA-code. Design page === Design have changed many times so I have drawn new high-level picture for you: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#Design This page also describes work flows related to replica management etc. It would be really nice if someone could review the whole design - some aspects have changed significantly. Proof of concept code = (described on design page; for adventurous or archaeologists) https://github.com/spacekpe/openssl/tree/aes_wrap_pad https://github.com/spacekpe/ipadnssecd https://github.com/spacekpe/python-ldap https://github.com/spacekpe/SoftHSMv2/tree/asym_wrap_api https://github.com/spacekpe/SoftHSMv2/tree/asym_wrap.sq https://github.com/spacekpe/SoftHSMv2/tree/cka_sensitive https://github.com/spacekpe/opendnssec/tree/cka_extractable https://github.com/spacekpe/freeipa-pkcs11 https://github.com/spacekpe/dnspython/commits/DNSKEY.flags_to_text_set Have a nice day(s). -- Petr^2 Spacek ___ 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/21/2014 6:35 AM, Petr Vobornik wrote:
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?
You're right, there is an error. Attaching new version. The code is
rewritten to be more comprehensible - use cases are in separate variables.
ACK. The code now makes more sense.
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 709 webui: fix nested items creation in dropdown list
On 7/21/2014 6:51 AM, Petr Vobornik wrote: Items nested in other items were created in root list instead of nested list. Note: this feature is not used in current UI but it's likely to be used by a plugin ACK. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 713-714 webui: replace action_buttons with action_widget
On 7/23/2014 8:26 AM, Petr Vobornik wrote: [PATCH] 713 webui: replace action_buttons with action_widget Simplify code base by reuse of 'disable' feature of button_widget. All occurrences of action-button which were disabled/enabled were replaced by button-widget. https://fedorahosted.org/freeipa/ticket/4258 [PATCH] 714 webui: remove remaining action-button-disabled occurrences Buttons in hbactest check for 'action-button-disabled' but it's never set. https://fedorahosted.org/freeipa/ticket/4258 ACK. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 712 webui: detach facet nodes
On 7/23/2014 8:25 AM, Petr Vobornik wrote:
Detach/attach facet nodes when switching facets instead of
hiding/showing.
Keeps dom-tree more simple.
This patch is not really needed. I implemented it while testing
something in IE. But it might have positive effect for poorly written
parts of Web UI(if there are any :) ) or plugins. Basically it
simplifies DOM tree to contain nodes only for the active facet.
Therefore ugly expressions like $('button .foobar') are much more
performant.
ACK. In the future the entire facet itself probably can even be loaded
dynamically, so this is a step in that direction. The facet element
itself probably can be merged with the content element since there's
only one facet/content at any time.
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 710 webui: review pending operation after expired session
On 7/23/2014 8:16 AM, Petr Vobornik wrote: Disable automatic re-execution of command after pending authentication. It's possible to enable it again globally by 'freeipa/config':`rpc_retry_auth`. https://fedorahosted.org/freeipa/ticket/4374 # Additional info: This ticket is in 4.0 stabilization milestone. I don't think it's the best fit. It has a potential to break things. It's also harder to test because integration tests don't test it - one has to remove session cookie every time and then react appropriately. It's also first usage of ./config module (other items there are not used). This module was originally implemented to contain global webui config which could be overwritten by config configured on server, ie for disabling paging in large deployments. The server part doesn't exist yet. Other reason is to split ipa.js into more single-purpose files. It works a little bit differently than expected. Right now suppose I'm trying to delete a user, I have the delete dialog open and I let it sit until the session expires, then when I click Delete it will show me a login screen. Once I re-login, the dialog box is gone. It still has the user to be deleted selected, but there's no indication what the operation I was trying to do before. I was thinking the session expiration would work like desktop screensaver lock. So when I re-login I would see same screen as I left it, i.e. the delete dialog is still waiting for action. The patch itself is fine, so it's ACKed, but I'll let you decide if this is sufficient to close the bug. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 711 webui: internet explorer fixes
On 7/24/2014 11:36 AM, Petr Vobornik wrote: On 23.7.2014 15:17, Petr Vobornik wrote: Fixed: 1. IE doesn't support value 'initial' in CSS rule. 2. setting innerHTML='' also destroys content of child nodes in LoginScreen in IE - reattached buttons have no text. Should go into 4.0 Milestone Found an issue in the implementation, new version attached. ACK. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 715 webui: add bounce url to reset_password.html
On 7/23/2014 9:59 AM, Petr Vobornik wrote:
reset_password.html now redirects browser to URL specified in 'redirect'
uri component (if present).
The component has to be URI encoded. ie (in browser console):
$
encodeURIComponent('http://pvoborni.fedorapeople.org/doc/#!/guide/Debugging')
--
http%3A%2F%2Fpvoborni.fedorapeople.org%2Fdoc%2F%23!%2Fguide%2FDebugging
--
https://my.freeipa.server/ipa/ui/reset_password.html?redirect=http%3A%2F%2Fpvoborni.fedorapeople.org%2Fdoc%2F%23!%2Fguide%2FDebugging
https://fedorahosted.org/freeipa/ticket/4440
ACK. Just one thing, there is no pause between clicking the Reset button
and the redirection, so the Password reset was successful.
confirmation message might only appear very briefly. A possible
alternative is to show a confirmation page/message, but the user will
have to click to continue to the next page.
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
