Re: [Freeipa-devel] LDAP schema for DNSSEC keys
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. (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). Simo. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
On 23.6.2014 14:57, Petr Spacek wrote: Hello list, I'm working on key wrapping mechanism described in thread LDAP schema for DNSSEC keys [0] and I'm really puzzled from the maze of crypto here. I would really appreciate any suggestions or comments on this. - I have difficulties to pick and use proper wrapping mechanisms and their configuration/usage patterns. - Rick van Rein from OpenDNSSEC-user list noted that we are defeating purpose of PKCS#11 by exporting raw keys from HSM. I can see his point and we should be able to do all crypto operations inside SoftHSM. I have asked him to describe his doubts on freeipa-devel list - stay tuned. We need to wrap === - asymmetric key (zone key) with symmetric key (master key) - symmetric key (master key) with asymmetric key (replica key) LDAP schema prescribes some storage formats but my question is about crypto algorithms (and padding!) used for key wrapping. Asymmetric keys === According to schema [1] wrapped asymmetric (i.e. private) key must be stored in 'ipaPrivateKey' attribute as DER-encoded EncryptedPrivateKeyInfo structure according to RFC 5958 [2]. It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData part of EncryptedPrivateKeyInfo structure so we only have to add algorithm identifier, DER-encode the whole thing, and we could be done. I'm not sure where should I stick IV or what happens if default (fixed) IV value is left in place...? Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with AES according to RFC 3394 (no padding) or RFC 5649 (with padding). RFC 3394 works only on blocks of 64 bits, which is not our case because EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get proper padding etc. And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but OpenSSL doesn't support RFC 5649! The patch with this functionality was submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state new and there was no reply to the e-mail in the original thread [4]. Does this mean SoftHSM does not support RFC 5649? What do we do? - Convince OpenSSL to review and accept the patch? - Hack it around #0: Use something else as key wrapping method? Other wrapping methods would require SoftHSM modification because SoftHSM supports only AES mechanisms now. - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a downstream patch in SoftHSM? Do we have enough expertise to implement it correctly? - Hack it around #2: Implement raw key extraction from SoftHSM and do key wrapping somehow somewhere? (Please nooo.) Symmetric keys == should be stored in 'ipaSecretKey' attribute but detailed storage format definition is missing from schema [1] right now. I thought we already agreed on using raw encrypted blob. Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with asymmetric key as *wrapping* key so we need to add this functionality. The first question is: What algorithm and padding scheme should we use? I guess PKCS#1 RSA or PKCS#1 RSA OAEP. Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]? That would be relatively easy to implement to SoftHSM because it is already there, just not handled in C_WrapKey (so we need to add appropriate 'glue' there). Another question is storage format of the wrapped key. PKCS#11 2.40d2 [7] contains this comment about PKCS #1 RSA OAEP algorithm: For wrapping, the “input” to the encryption operation is the value of the CKA_VALUE attribute of the key that is wrapped; similarly for unwrapping. The mechanism does not wrap the key type or any other information about the key, except the key length; the application must convey these separately. AFAIK it means that it wraps raw secret key and nothing else. If I'm not wrong we should be able to take resulting blob and stick it into OneSymmetricKey structure from RFC 6031 [5]. Honza, is it correct assumption/idea? What is the benefit of using OneSymmetricKey here? There is no wrapping algorithm identifier as in EncryptedPrivateKeyInfo and the whole thing looks very PSKC-specific. I would really appreciate any suggestions or comments on this. Thank you for your time. [0] https://www.redhat.com/archives/freeipa-devel/2014-April/msg00565.html [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 [2] http://tools.ietf.org/html/rfc5958#section-3 [3] http://rt.openssl.org/Ticket/Display.html?id=2204 [4] http://marc.info/?l=openssl-devm=126953517430167w=2 [5] https://tools.ietf.org/html/rfc6031#section-2 [6] https://www.openssl.org/docs/crypto/RSA_public_encrypt.html [7] http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/csprd02/pkcs11-curr-v2.40-csprd02.html#_Toc387327841 -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
On 23.6.2014 13:01, Martin Kosek wrote:
On 06/18/2014 02:09 PM, Jan Cholasta wrote:
...
3) I am thinking why do we need to introduce all the ASN parsing? I am talking
about _decode_krb5principalname and others. If we do not use the result
anywhere, why should we include this part at all?
To work around shortcomings of NSS/python-nss. In particular,
_decode_krb5principalname is used to decode KRB5PrincipalName SANs to a string.
This is necessary because certmonger puts such SANs in certificate requests it
generates.
I know, but we do not use the values besides DNS SAN type, right? I was just
afraid that a decode error in a decoding of an unused SAN type would cause the
entire CSR processing to crash.
If we do not allow principal name SANs, requests from certmonger will fail. If
we allow them, but ignore them, you could request a certificate for an
arbitrary unrelated principal. Thus, the only thing we can do is allow them and
validate them, which is what the patch does and why decoding KRB5PrincipalName
is necessary.
True, we need to make sure the principal type SANs match. ack on the intent.
4) I get crash in the certmonger request:
ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r
-N cn=`hostname` -K host/`hostname` -D test1.example.com -D
test2.example.com
-E mko...@redhat.com
# ipa-getcert list -i test-san-1
Number of certificates and requests being tracked: 8.
Request ID 'test-san-1':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: -504 (HTTP response code is
500,
not 200).
stuck: yes
HTTPD traceback
[Mon Jun 16 13:06:14.528642 2014] [:error] [pid 12941] [remote
...
PyAsn1Error: TagSet(Tag(tagClass=128, tagFormat=0, tagId=2)) not in asn1Spec:
_GeneralName()
What version of certmonger are you using?
Latest Fedora 20, i.e. should be certmonger-0.71.2-1.fc20 (do not have access
to my VM atm). Is this a bug in certmonger?
No, it's bug in my code. Fixed.
Works.
Also added patch 301 which fixes a bug in ldap2.get_effective_rights I was
hitting with patch 234.
Updated patches attached.
Thanks. Functionally, the patch looks ok to me, we are close to final ack. Just
couple more minor changes need to happen:
1) We decided to drop ipaVirtualOperation concept in the end and allow people
reading this list. This implies following changes:
234 - drop ipaVirtualOperation from cn=request certificate with
subjectaltname,cn=virtual operations,cn=etc,$SUFFIX
300 - drop the entire patch (sorry)
OK.
2) I would like to have more confidence that no unauthorized SAN extension gets
in. I know we have the
+for name_type, name in subjectaltname:
+if name_type not in (pkcs10.SAN_DNSNAME,
loop, but I would also like to add else path to the SAN type validation loop,
in case somebody just expands the part above, but forgot to also add
validation. I want us to be explicit in this case:
+for name_type, name in subjectaltname:
+if name_type == pkcs10.SAN_DNSNAME:
...
+elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME,
+ pkcs10.SAN_OTHERNAME_UPN):
...
else:
raise errors.ACIError(info=_(
Unauthorized subject alt name '%s'.) % name)
Fixed.
When this is fixed, we should be done.
Thanks,
Martin
Updated and rebased patches attached.
--
Jan Cholasta
From 26cfd1e4b12e84861b19028e8c81befc8e4bca8e Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Thu, 5 Dec 2013 14:34:14 +0100
Subject: [PATCH 1/3] Allow SAN in IPA certificate profile.
https://fedorahosted.org/freeipa/ticket/3977
---
install/tools/ipa-upgradeconfig | 7 +-
ipaserver/install/cainstance.py | 51 +
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index 99dfbdf..688e178 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -330,9 +330,14 @@ def upgrade_ipa_profile(ca, domain, fqdn):
root_logger.debug('Subject Key Identifier updated.')
else:
root_logger.debug('Subject Key Identifier already set.')
+san = ca.enable_subject_alternative_name()
+if san:
+root_logger.debug('Subject Alternative Name updated.')
+else:
+root_logger.debug('Subject Alternative Name already set.')
audit = ca.set_audit_renewal()
uri = ca.set_crl_ocsp_extensions(domain, fqdn)
-if audit or ski or uri:
+if audit or ski or san or uri:
return True
else:
root_logger.info('CA is not configured')
diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index b5c6cdc..b13a77d 100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -464,6 +464,7 @@ class CAInstance(service.Service):
Re: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade
On 23.6.2014 17:49, Martin Basti wrote: On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote: Hello, I have following issues: #1 Upgrading existing replicas to support DNSSEC won't work for current design (replica-file as storage for temporal replica key). Temporal private key needs to be copied to replica, and no encrypted master-key for replica is prepared in LDAP, because user doesn't need to run ipa-replica-prepare. After discussion with Petr2, the solution is: a) Each replica (except first - which generates master-key) generates replica public and private keys. b) Replica uploads public key to LDAP c) Replica with generated master key, use the public key (b) to encrypt master-key and store it to LDAP. Replica with master-key must detect, if there is any new public replica key. d) Replica (b) is now able to get master-key using own private replica key #2 We need to choose only one replica which will generate, (rotate, ...) DNSSEC keys. and generate master key too My proposal is to test during installation/upgrade if any dnssec/master keys are in LDAP. If no key was found, the first server is installed/upgraded and DNSSEC key generator is required. But there is issue with parallel upgrade multiple replicas (or if replication temporarily doesn't work). There is no guarantee if replicas will be able to detect if any replica became DNSSEC key generator. Let me add that we are going to use syncrepl anyway so the overall latency should be minimal (if replication works). -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
On 06/24/2014 11:30 AM, Jan Cholasta wrote: On 23.6.2014 13:01, Martin Kosek wrote: On 06/18/2014 02:09 PM, Jan Cholasta wrote: ... 3) I am thinking why do we need to introduce all the ASN parsing? I am talking about _decode_krb5principalname and others. If we do not use the result anywhere, why should we include this part at all? To work around shortcomings of NSS/python-nss. In particular, _decode_krb5principalname is used to decode KRB5PrincipalName SANs to a string. This is necessary because certmonger puts such SANs in certificate requests it generates. I know, but we do not use the values besides DNS SAN type, right? I was just afraid that a decode error in a decoding of an unused SAN type would cause the entire CSR processing to crash. If we do not allow principal name SANs, requests from certmonger will fail. If we allow them, but ignore them, you could request a certificate for an arbitrary unrelated principal. Thus, the only thing we can do is allow them and validate them, which is what the patch does and why decoding KRB5PrincipalName is necessary. True, we need to make sure the principal type SANs match. ack on the intent. 4) I get crash in the certmonger request: ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r -N cn=`hostname` -K host/`hostname` -D test1.example.com -D test2.example.com -E mko...@redhat.com # ipa-getcert list -i test-san-1 Number of certificates and requests being tracked: 8. Request ID 'test-san-1': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (HTTP response code is 500, not 200). stuck: yes HTTPD traceback [Mon Jun 16 13:06:14.528642 2014] [:error] [pid 12941] [remote ... PyAsn1Error: TagSet(Tag(tagClass=128, tagFormat=0, tagId=2)) not in asn1Spec: _GeneralName() What version of certmonger are you using? Latest Fedora 20, i.e. should be certmonger-0.71.2-1.fc20 (do not have access to my VM atm). Is this a bug in certmonger? No, it's bug in my code. Fixed. Works. Also added patch 301 which fixes a bug in ldap2.get_effective_rights I was hitting with patch 234. Updated patches attached. Thanks. Functionally, the patch looks ok to me, we are close to final ack. Just couple more minor changes need to happen: 1) We decided to drop ipaVirtualOperation concept in the end and allow people reading this list. This implies following changes: 234 - drop ipaVirtualOperation from cn=request certificate with subjectaltname,cn=virtual operations,cn=etc,$SUFFIX 300 - drop the entire patch (sorry) OK. 2) I would like to have more confidence that no unauthorized SAN extension gets in. I know we have the +for name_type, name in subjectaltname: +if name_type not in (pkcs10.SAN_DNSNAME, loop, but I would also like to add else path to the SAN type validation loop, in case somebody just expands the part above, but forgot to also add validation. I want us to be explicit in this case: +for name_type, name in subjectaltname: +if name_type == pkcs10.SAN_DNSNAME: ... +elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, + pkcs10.SAN_OTHERNAME_UPN): ... else: raise errors.ACIError(info=_( Unauthorized subject alt name '%s'.) % name) Fixed. When this is fixed, we should be done. Thanks, Martin Updated and rebased patches attached. This looks good. We can finally push this beast. Note that we should also add proper tests in future exercising the new functionality. ACK. Pushed to master: 8b8774d138348ab4b938f98dc106ea983e261262 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0594-0606 Convert default permissions to managed
On 06/24/2014 12:27 PM, Petr Viktorin wrote: On 06/23/2014 05:51 PM, Martin Kosek wrote: On 06/23/2014 02:59 PM, Petr Viktorin wrote: On 06/23/2014 10:07 AM, Martin Kosek wrote: On 06/20/2014 11:17 PM, Martin Kosek wrote: On 06/20/2014 05:06 PM, Petr Viktorin wrote: All these should be independent, except for conflicts in ACI.txt that are easily solved by running makeaci. Umh, now the fun begins as I see :) There will probably need to be some rebase, it clashed with some other ACI patches in my tree (namely Hosts which I acked). Rebased on top of my patch 0607, please apply that first. Added a new patch, 0608, which adds missing write permissions. 594: we miss permissions for Automount Locations. Permissions for keysmaps look ok. Added in 0608. 595: System: Modify Group Membership is probably waiting for the group objectclass fix - the filter is different. Otherwise it looks ok. Right; rebased. 596-598: HBAC is ok 599: hostgroup is OK 600: there must have been some DS problem on my side as my regular user could not see any netgroup The problem is a bit closer to home this time. Fixed in patch 0607. 601: privileges - we miss CRUD ACIs Added in 0608. We also miss CRUD permissions on permissions, but since currently these need pretty much unlimited access to ACIs, it's better to keep them admin-only. 602: roles were ok 603: ok I got this far today, the rest will need to wait for the next week. 604: ok, I was able to create a service, get a keytab 605: Should we case the permissions as Sudo Command instead of Sudo command? Yes, fixed 606: we also miss Modify Sudo Command permission so that people can modify description. Otherwise ok. Added in 0608. 1) # ipa-server-install: ... Applying LDAP updates ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERRORAdd failure missing required attribute objectclass ... There is a problem in this pending update: dn: cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX add:member: 'cn=Modify Group membership,cn=privileges,cn=pbac,$SUFFIX' You apparently also need to make this permission also a member of Modify Group membership privilege. Fixed, thank you. 2) We may not need System: Modify Automount Locations as there is just the CN and we do not support renames in automountlocation API. I am not insisting. Removed. When these 2 issues are resolved, we can push. I've also added a patch that fixes a permission-find test which assumed there are many old permissions. Are you sure you tested the patches? 1) This change in 595 looks suspicious: dn: $SUFFIX -# Don't allow the default 'manage group membership' to be able to manage the -# admins group -replace:aci:'(targetattr = member)(target = ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Modify Group membership;allow (write) groupdn = ldap:///cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX;)::(targetfilter = (!(cn=admins)))(targetattr = member)(target = ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Modify Group membership;allow (write) groupdn = ldap:///cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX;)' It lefts the update file with dn: $SUFFIX dn: cn=ipa,cn=etc,$SUFFIX add:aci:'(target = ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX;)(version 3.0; acl Add CA Certific ... 2) About patch 609.3 - this test still looks very fragile. It would break just with adding one more permission to SUFFIX. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 647-651 [webui] Make utility section of navigation extensible
On 23.6.2014 18:35, Endi Sukma Dewata wrote:
On 6/23/2014 8:15 AM, Petr Vobornik wrote:
1. I'm not sure if we really need a HashCreator. Ideally the router
should map a hash to a page. Links to another page can be hardcoded too
(and substitute the parameters).
The main purpose of a hash creator is to update hash when a facet state
changes. This change can be initiated from the facet itself, e.g. when
searching in a search facet. Removing the hash creator would make facets
dependent on navigation specifics.
I was thinking if the facet itself is changing the state, it will only
change the query part of the URL. The base facet URL itself is assigned
by the router. I think we used to put all UI states in the URL so that's
why we needed a hash creator.
My thinking was that the facet shouldn't be even aware of the hash or
routing.
I would agree if it was related only to links. But even then it would be
better to have a method which would create the hash (for the one which
shares the same pattern) to reduce code reuse. In any case, it's
possible to hardcode hash parts in links if one needs to.
It's more about removing dependencies between pages. For example, to
link from one page to another we use something like this:
navigation.show_entity(entity.name, facetname, [pkey]);
This means we're explicitly handling the link. And this also puts
additional restrictions such as the target page must be an entity page
which has one level sub page called 'facetname' that takes one primary
key. If the target page is not an entity page we'd have to use a
different method.
I think it would be cleaner if the link can be defined in a (future)
template like this:
a href=#/{entity}/{facet}/{pkey}
How is this different? You still have to pass the entity, facet name and
pkey. You just moved the logic form hash creator to the template. And I
can bet that doing something more difficult there will be a pain.
Also it doesn't work for redirection initiated by other means then a
link, e.g., when something gets deleted.
If one wants to create a link in a template he could use some link
helper which would internally call the hash creator.
Note that the template is used to generate the links only. When the user
clicks the link we rely on the browser, or other routing libraries, to
handle it so less code to maintain and it puts the UI workflow in the
hands of UI designers.
Keeping facet and widget internals out of direct hash modification
allows to embed the whole app or just some parts of it into other app.
Or we can have two different or same facets displayed next to each
other. Atm this is not an argument since we do not make it with this use
case in mind. The same applies for code modifications by designers.
2. Ideally there should be no entity-specific navigation code. All
routing should be handled in a generic way. This probably depends on the
entity-facet separation that we discussed previously. So routes like
this:
/e/:entity/:facet/:pkeys/*args
should be replaced by individual routes for each entity:
/user/:facet/:pkeys/*args
/group/:facet/:pkeys/*args
Yes, but IMHO the hash prefix is a detail. It would be more important if
it would be a REST API where it's a core aspect.
Right, a REST URL probably would look like:
/ipa/ui/users/{facet}/{pkey}?{query}
And ideally if you open a REST URL in a browser you should get a UI. So
anything that brings the UI closer to this would be great.
4. The args/query in the navigation paths should be separated by a more
standard delimiter ? instead of //. For example:
/ipa/ui/#/e/user/search//filter=test
should be replaced with:
/ipa/ui/#/e/user/search?filter=test
note that // is a result of /:pkeys/, where :pkeys is '' Therefore a
simple replacement would lead to
/ipa/ui/#/e/user/search/?filter=test
Please file a ticket, if you think it's important.
I was originally thinking this to be a way to mimic the REST URL, but
now I'm not sure if it would interfere with URL parsing because in this
case the ? will be part of the URL hash, not URL query, so maybe we
should just leave it for now.
Lets say that we would implement #2 and #4. Would we also want to keep
the old routes for backwards compatibility? (main purpose of hashes is
to make the page bookmarkable). IMHO people don't care about #2 and #4
much, but they care about broken bookmarks.
The hashes are probably more useful to make the browser's Back button
functional. Bookmarking is probably a secondary benefit, but are there
pages in the UI that people would likely to bookmark? An admin probably
would just bookmark the main URL, not a particular page in the UI.
Backward compatibility of routing is nice, but I don't think it's a hard
requirement.
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] [WIP] ipatest/util: Use YAML-diff for reporting differences in assert_deepequal
Hello, With this patch applied and python-PyYAML installed, failed declarative tests will output a diff between the full expected/got structures, so you can see all the context and all the differences at once. (I use YAML because it diffs very nicely, at least with the options used here.) It's a hack/proof of concept, but I tried extra hard ensure it passes/fails in the same cases as the original assert_deepequal. If you don't have python-PyYAML installed, the original assert_deepequal is used. Feel free to use it if it helps. -- Petr³ From ccaf260b7a5ad0608a3e953925d59080b96f75bc Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Fri, 20 Sep 2013 15:22:30 +0200 Subject: [PATCH] [WIP] ipatest/util: Use YAML-diff for reporting differences in assert_deepequal Unlike the errors from the original assert_deepequal, this format shows all context and all differences. The old function is kept as assert_deepequal_original, and checked to ensure they raise in exactly the same situations. If the YAML library is not available, the original implementation is used. --- ipatests/test_util.py | 2 +- ipatests/util.py | 167 +++--- 2 files changed, 161 insertions(+), 8 deletions(-) diff --git a/ipatests/test_util.py b/ipatests/test_util.py index f87822a223f017f54f8b3bf5f6319b66e97482a7..9562513976c4a9104bdfdd9ae4146bd4056da844 100644 --- a/ipatests/test_util.py +++ b/ipatests/test_util.py @@ -130,7 +130,7 @@ def test_eq(self): def test_assert_deepequal(): -f = util.assert_deepequal +f = util.assert_deepequal_original # Test with good scalar values: f(u'hello', u'hello') diff --git a/ipatests/util.py b/ipatests/util.py index 30fafdc76c3a139d954c6d7a5ad4c05360fe6de6..4436cab3a70d694edf31361a3d09a125b96f60f3 100644 --- a/ipatests/util.py +++ b/ipatests/util.py @@ -24,17 +24,29 @@ import inspect import os from os import path -import ldap -import ldap.sasl -import ldap.modlist +import difflib +from itertools import izip_longest import tempfile import shutil import re +import pprint + +import ldap +import ldap.sasl +import ldap.modlist + import ipalib from ipalib.plugable import Plugin from ipalib.request import context from ipapython.dn import DN +try: +import yaml +except ImportError: +have_yaml = False +else: +have_yaml = True + class TempDir(object): def __init__(self): @@ -275,7 +287,7 @@ def __ne__(self, other): path = %r -def assert_deepequal(expected, got, doc='', stack=tuple()): +def assert_deepequal_original(expected, got, doc='', stack=tuple()): Recursively check for type and equality. @@ -290,7 +302,7 @@ def assert_deepequal(expected, got, doc='', stack=tuple()): got = [u'Hello', dict(world='how are you?')] expected == got True - assert_deepequal(expected, got, doc='Testing my nested data') + assert_deepequal_original(expected, got, doc='Testing my nested data') Traceback (most recent call last): ... AssertionError: assert_deepequal: type(expected) is not type(got). @@ -329,7 +341,7 @@ def assert_deepequal(expected, got, doc='', stack=tuple()): s_expected = sorted(expected) for (i, e_sub) in enumerate(s_expected): g_sub = s_got[i] -assert_deepequal(e_sub, g_sub, doc, stack + (i,)) +assert_deepequal_original(e_sub, g_sub, doc, stack + (i,)) elif isinstance(expected, dict): missing = set(expected).difference(got) extra = set(got).difference(expected) @@ -341,7 +353,7 @@ def assert_deepequal(expected, got, doc='', stack=tuple()): for key in sorted(expected): e_sub = expected[key] g_sub = got[key] -assert_deepequal(e_sub, g_sub, doc, stack + (key,)) +assert_deepequal_original(e_sub, g_sub, doc, stack + (key,)) elif callable(expected): if not expected(got): raise AssertionError( @@ -353,6 +365,147 @@ def assert_deepequal(expected, got, doc='', stack=tuple()): ) +def assert_deepequal_yaml(expected, got, doc='', stack=()): +Recursively check for type and equality + +This works the same as assert_deepequal_original, except it produces +more informative messages by showing a YAML diff. +The equivalent behavior is checked in every call. + +old_expected, old_got = expected, got +MISSING = object() + +def yaml_dump(structure): +Dump structure in a particularly diff-friendly style of YAML + +Use pprint as a fallback if yaml.safe_dum fails (e.g. because it +can't represent types that aren't pure data) + +try: +return yaml.safe_dump(structure, default_flow_style=False) +except Exception: +return pprint.pformat(structure) + +def normalize(expected, got, stack): +Recursively normalize ``expected`` and ``got`` for comparison diff + +
Re: [Freeipa-devel] [PATCHES] 0594-0606 Convert default permissions to managed
On 06/24/2014 01:26 PM, Petr Viktorin wrote: On 06/24/2014 12:35 PM, Martin Kosek wrote: On 06/24/2014 12:27 PM, Petr Viktorin wrote: On 06/23/2014 05:51 PM, Martin Kosek wrote: On 06/23/2014 02:59 PM, Petr Viktorin wrote: On 06/23/2014 10:07 AM, Martin Kosek wrote: On 06/20/2014 11:17 PM, Martin Kosek wrote: On 06/20/2014 05:06 PM, Petr Viktorin wrote: All these should be independent, except for conflicts in ACI.txt that are easily solved by running makeaci. Umh, now the fun begins as I see :) There will probably need to be some rebase, it clashed with some other ACI patches in my tree (namely Hosts which I acked). Rebased on top of my patch 0607, please apply that first. Added a new patch, 0608, which adds missing write permissions. 594: we miss permissions for Automount Locations. Permissions for keysmaps look ok. Added in 0608. 595: System: Modify Group Membership is probably waiting for the group objectclass fix - the filter is different. Otherwise it looks ok. Right; rebased. 596-598: HBAC is ok 599: hostgroup is OK 600: there must have been some DS problem on my side as my regular user could not see any netgroup The problem is a bit closer to home this time. Fixed in patch 0607. 601: privileges - we miss CRUD ACIs Added in 0608. We also miss CRUD permissions on permissions, but since currently these need pretty much unlimited access to ACIs, it's better to keep them admin-only. 602: roles were ok 603: ok I got this far today, the rest will need to wait for the next week. 604: ok, I was able to create a service, get a keytab 605: Should we case the permissions as Sudo Command instead of Sudo command? Yes, fixed 606: we also miss Modify Sudo Command permission so that people can modify description. Otherwise ok. Added in 0608. 1) # ipa-server-install: ... Applying LDAP updates ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERRORAdd failure missing required attribute objectclass ... There is a problem in this pending update: dn: cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX add:member: 'cn=Modify Group membership,cn=privileges,cn=pbac,$SUFFIX' You apparently also need to make this permission also a member of Modify Group membership privilege. Fixed, thank you. 2) We may not need System: Modify Automount Locations as there is just the CN and we do not support renames in automountlocation API. I am not insisting. Removed. When these 2 issues are resolved, we can push. I've also added a patch that fixes a permission-find test which assumed there are many old permissions. Are you sure you tested the patches? Yes. Not enough, I'm sure, but I did test them... 1) This change in 595 looks suspicious: dn: $SUFFIX -# Don't allow the default 'manage group membership' to be able to manage the -# admins group -replace:aci:'(targetattr = member)(target = ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Modify Group membership;allow (write) groupdn = ldap:///cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX;)::(targetfilter = (!(cn=admins)))(targetattr = member)(target = ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Modify Group membership;allow (write) groupdn = ldap:///cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX;)' It lefts the update file with dn: $SUFFIX dn: cn=ipa,cn=etc,$SUFFIX add:aci:'(target = ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX;)(version 3.0; acl Add CA Certific ... Right. (It's removed in one of the later patches, so I didn't catch it.) 2) About patch 609.3 - this test still looks very fragile. It would break just with adding one more permission to SUFFIX. It follows the general style of declarative tests, which depend on a freshly installed system. I think it's a good test to have around, at least until there's a better suite for permission-find on legacy permissions. Ok, as you wish. The patch set now looks good to me, tests are also good. ACK to all, I pushed them all to master. This pretty much concludes the ground work on permission/aci refactoring - good job Petr! :-) Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command
On Tue, 03 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote:
On 3.6.2014 05:08, Nathaniel McCallum wrote:
This command calls the token sync HTTP POST call in the server providing
the CLI interface to synchronization.
https://fedorahosted.org/freeipa/ticket/4260
This patch depends on my patch #0055.
Build fails on validation. You forgot to update API.txt and also the
command misses __doc__.
(not a proper review)
Failed for me:
[root@ipa-01 rpms]# ipa otptoken-show test.token
Unique ID: test.token
Description: test token
Owner: abbra
Vendor: FreeIPA
Model: hotp
[root@ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token
Password:
First Code:
Second Code:
ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized',
httplib.HTTPMessage instance at 0x2cdde60)
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 129,
in execute
result = self.Command[_name](*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439,
in __call__
ret = self.run(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 1118,
in run
return self.forward(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py,
line 427, in forward
rsp = urllib.urlopen(sync_uri, query)
File /usr/lib64/python2.7/urllib.py, line 89, in urlopen
return opener.open(url, data)
File /usr/lib64/python2.7/urllib.py, line 210, in open
return getattr(self, name)(url, data)
File /usr/lib64/python2.7/urllib.py, line 454, in open_https
data)
File /usr/lib64/python2.7/urllib.py, line 374, in http_error
result = method(url, fp, errcode, errmsg, headers, data)
File /usr/lib64/python2.7/urllib.py, line 689, in http_error_401
errcode, errmsg, headers)
File /usr/lib64/python2.7/urllib.py, line 381, in http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 401, 'Unauthorized', httplib.HTTPMessage instance at
0x2cdde60)
ipa: ERROR: an internal error has occurred
Note that I can successfully use the token. It looks like authentication
with urllib.urlopen(sync_uri, query) fails.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0233] trusts: Add more read attributes
Hi,
this is a follow up patch for 232. Read access to additional attributes
is required for the trust objects.
--
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 8a0849d4bf59b61715ba7b055e980cc38a9fcd6a Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Tue, 24 Jun 2014 13:58:28 +0200
Subject: [PATCH] trusts: Add more read attributes
---
ACI.txt | 2 +-
ipalib/plugins/trust.py | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/ACI.txt b/ACI.txt
index 11af74a3d7155e92debe089dc15c7306ad120258..0398a52fcf2639f895f6bb7cd8bd91412affa6d3 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -111,7 +111,7 @@ aci: (targetattr = cmdcategory || cn || description || externalhost || external
dn: cn=System: Read Sudoers compat tree,cn=permissions,cn=pbac,dc=ipa,dc=example
aci: (targetattr = cn || description || objectclass || ou || sudocommand || sudohost || sudonotafter || sudonotbefore || sudooption || sudoorder || sudorunas || sudorunasgroup || sudorunasuser || sudouser)(target = ldap:///ou=sudoers,dc=ipa,dc=example;)(version 3.0;acl permission:System: Read Sudoers compat tree;allow (compare,read,search) userdn = ldap:///all;;)
dn: cn=System: Read Trust Information,cn=permissions,cn=pbac,dc=ipa,dc=example
-aci: (targetattr = cn || ipantflatname || ipantsecurityidentifier || ipanttrusteddomainsid || objectclass)(version 3.0;acl permission:System: Read Trust Information;allow (compare,read,search) userdn = ldap:///all;;)
+aci: (targetattr = cn || ipantflatname || ipantsecurityidentifier || ipantsidblacklistincoming || ipantsidblacklistoutgoing || ipanttrusteddomainsid || ipanttrustpartner || objectclass)(version 3.0;acl permission:System: Read Trust Information;allow (compare,read,search) userdn = ldap:///all;;)
dn: cn=System: Add User to default group,cn=permissions,cn=pbac,dc=ipa,dc=example
aci: (targetattr = member)(target = ldap:///cn=ipausers,cn=groups,cn=accounts,dc=ipa,dc=example;)(version 3.0;acl permission:System: Add User to default group;allow (write) groupdn = ldap:///cn=System: Add User to default group,cn=permissions,cn=pbac,dc=ipa,dc=example;)
dn: cn=System: Add Users,cn=permissions,cn=pbac,dc=ipa,dc=example
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 987fb7476d62b7aba5ef304d01a6d5922235d5b1..25755d7a41e93b869f4d4afbf0ac094c42212451 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -326,7 +326,8 @@ class trust(LDAPObject):
'ipapermdefaultattr': {
'cn', 'objectclass',
'ipantflatname', 'ipantsecurityidentifier',
-'ipanttrusteddomainsid',
+'ipanttrusteddomainsid', 'ipanttrustpartner',
+'ipantsidblacklistincoming', 'ipantsidblacklistoutgoing'
},
},
}
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 632 webui: simplify self-service menu
On 12.6.2014 14:53, Endi Sukma Dewata wrote: On 6/11/2014 10:17 AM, Endi Sukma Dewata wrote: On 6/11/2014 6:06 AM, Petr Vobornik wrote: 1. If I recall correctly, a new user is required to change the password upon the initial login. This can be done with kinit, but can this be done via UI too? Right now a new user will get a login error without any message or link to reset the password. It works for me. There was a ticket https://fedorahosted.org/freeipa/ticket/4339 which corresponds to the description. Or it could be related to: https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=c41b782bc59cd0cb70cbd62d543f9c538109d410 (if you use an IPA version before the revert) I just built the master yesterday. Let me see if I can reproduce it with a newer build. I'm still seeing the problem in the new build. Here are the steps to reproduce: 1. Login as admin. 2. Add a new user with a password. 3. Logout. 4. Login as the new user. It will say The password or username you entered is incorrect. There's no message about expiration or link to change the password. So far the only way to change the password is via kinit. Found the culprit. It was caused by utc vs local time comparison. Patch #676 should fix it. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
Tomas Mraz: On, 2014-06-23 at 14:57 +0200, Petr Spacek wrote: We need to wrap === - asymmetric key (zone key) with symmetric key (master key) - symmetric key (master key) with asymmetric key (replica key) Can you please provide more info what purpose these keys have? I understand that the zone key is the DNSSEC asymmetric key for the zone. But what about the master key and replica key? Why the master key is symmetric and the replica asymmetric? What we want is the ability to store keys in LDAP so that multiple servers can generate DNSSEC keys. This allows no single points of failure, and also allows local servers to generate signatures for DNS names that may differ from replica to replica in the future (think things like views). In order to do that each DNS server need access to the Zone keys, but we do not want to distribute the unencrypted in LDAP. We also do not want to have to invent a parallel distribution method to send these keys to all the replicas that need them. We do have a private/public key pair on each replica though so we can use this fact to wrap a symmetric master key with all the public keys of the replicas that need access to the zone keys, and encrypt the zone keys with this master key. The reason to use a symmetric in the middle is that is allows for a few things: 1. it is easy to re-encrypt it t replica creation time by one of the other servers as soon as the replica is built and publishes its on key. This solves the distribution problem to new replicas. This same mechanism also allows to redistribute a new key if you need/want to rotate it for whatever reason. It also avoids the need to encrypt every zone private key multiple times with each replica public key, which would cause a lot of churn. HTH, Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 676 rpcserver: fix local vs utc time comparison
login_password did not work properly in timezones other than +0h because local time was compared with utc time. Bug introduced in: https://fedorahosted.org/freeipa/ticket/4339 We should review other code for invalid usage of datetime.now() -- Petr Vobornik From 0c60c536a7f91226fa0201568b2be99dba7b02c9 Mon Sep 17 00:00:00 2001 From: Petr Vobornik pvobo...@redhat.com Date: Tue, 24 Jun 2014 15:54:41 +0200 Subject: [PATCH] rpcserver: fix local vs utc time comparison login_password did not work properly in timezones other than +0h because local time was compared with utc time. Bug introduced in: https://fedorahosted.org/freeipa/ticket/4339 --- ipaserver/rpcserver.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py index 30b9746397636128c0edc3fb4d2ad7f7bdc22495..0838ad143c4c2ec9aa5fd7db3027b70ba6fa5a92 100644 --- a/ipaserver/rpcserver.py +++ b/ipaserver/rpcserver.py @@ -959,7 +959,7 @@ class login_password(Backend, KerberosSession, HTTP_Status): ['krbpasswordexpiration']) if 'krbpasswordexpiration' in entry_attrs: expiration = entry_attrs['krbpasswordexpiration'][0] -if expiration = datetime.datetime.now(): +if expiration = datetime.datetime.utcnow(): reason = 'password-expired' except Exception: -- 1.9.0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
- Original Message - Hello list, I'm working on key wrapping mechanism described in thread LDAP schema for DNSSEC keys [0] and I'm really puzzled from the maze of crypto here. I would really appreciate any suggestions or comments on this. - I have difficulties to pick and use proper wrapping mechanisms and their configuration/usage patterns. - Rick van Rein from OpenDNSSEC-user list noted that we are defeating purpose of PKCS#11 by exporting raw keys from HSM. I can see his point and we should be able to do all crypto operations inside SoftHSM. I have asked him to describe his doubts on freeipa-devel list - stay tuned. We need to wrap === - asymmetric key (zone key) with symmetric key (master key) - symmetric key (master key) with asymmetric key (replica key) LDAP schema prescribes some storage formats but my question is about crypto algorithms (and padding!) used for key wrapping. It is important to get these details right indeed, we must be able to change crypto algorithms if needed in the future, so algorithm agility must be part of the story. Asymmetric keys === According to schema [1] wrapped asymmetric (i.e. private) key must be stored in 'ipaPrivateKey' attribute as DER-encoded EncryptedPrivateKeyInfo structure according to RFC 5958 [2]. It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData part of EncryptedPrivateKeyInfo structure so we only have to add algorithm identifier, DER-encode the whole thing, and we could be done. Right. I'm not sure where should I stick IV or what happens if default (fixed) IV value is left in place...? We cannot use a fixed IV unless the wrapping algorithm uses an obfuscator within the data, otherwise you open yourself up for attacks. I expect the IV (if needed) to be provided by the SoftHSM itself ? If not something sounds broken. If the IV is fixed for some reason we culd provide the data with a secret confounder in the first block, but then we would not respect the standard in the first place. I will try to take a look at RFC 5958 once I am back at home tomorrow. Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with AES according to RFC 3394 (no padding) or RFC 5649 (with padding). RFC 3394 works only on blocks of 64 bits, which is not our case because EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get proper padding etc. We could also define how we generate padding ourselves if RFC 3394 is easier, although of course using RFC 5649 wuld be preferable rather than massaging the data ourselves. And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but OpenSSL doesn't support RFC 5649! The patch with this functionality was submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state new and there was no reply to the e-mail in the original thread [4]. What do we do? - Convince OpenSSL to review and accept the patch? If we are using a standard this is not as important, we can make our own implementation and then work with the OpenSSL community to get a proper implementation in. Does NSS implements it btw ? - Hack it around #0: Use something else as key wrapping method? Other wrapping methods would require SoftHSM modification because SoftHSM supports only AES mechanisms now. - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a downstream patch in SoftHSM? Do we have enough expertise to implement it correctly? - Hack it around #2: Implement raw key extraction from SoftHSM and do key wrapping somehow somewhere? (Please nooo.) No, let's use standards where they exist, it is ok to make our own implementation until upstream libraries finally get a good one, but let's avoid completely custom stuff. Symmetric keys == should be stored in 'ipaSecretKey' attribute but detailed storage format definition is missing from schema [1] right now. Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with asymmetric key as *wrapping* key so we need to add this functionality. The first question is: What algorithm and padding scheme should we use? We need algorithm agility here too, so I would use some generic envelope mechanism defined for encrypting data with asymetric keys and use it. If it is a good mechanism it will allow to use multiple algorithms and key sizes etc.. Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]? That would be relatively easy to implement to SoftHSM because it is already there, just not handled in C_WrapKey (so we need to add appropriate 'glue' there). I would not use something that ties us to RSA keys, it is probably highly desirable to use EC keys too as an alternative. Another question is storage format of the wrapped key. PKCS#11 2.40d2 [7] contains this comment about PKCS #1 RSA OAEP algorithm: For wrapping, the “input” to the encryption operation is the value of the
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
On Po, 2014-06-23 at 14:57 +0200, Petr Spacek wrote: Hello list, I'm working on key wrapping mechanism described in thread LDAP schema for DNSSEC keys [0] and I'm really puzzled from the maze of crypto here. I would really appreciate any suggestions or comments on this. I am not sure I am able to respond to all of your questions and problems you're trying to solve but let's try at least some. - I have difficulties to pick and use proper wrapping mechanisms and their configuration/usage patterns. - Rick van Rein from OpenDNSSEC-user list noted that we are defeating purpose of PKCS#11 by exporting raw keys from HSM. I can see his point and we should be able to do all crypto operations inside SoftHSM. I have asked him to describe his doubts on freeipa-devel list - stay tuned. It is really questionable what are you trying to achieve here. I would definitely stay away from trying to replicate any back-up mechanisms that eventual HSM (software or hardware one) should have. This is all fairly non-trivial functionality and if any HSM implementation is serious enough it should have backup facility of its own (which should also allow duplicating such HSM if needed). Note that simply allowing to export wrapped key with a key you provide to HSM during a normal operation (not as a special privileged operation) is defeating the purpose of HSM anyway as you can unwrap the protected key as you wish. So the only wrapping key that can be used in normal operation should be a key that is preset or pre-generated in the HSM by the HSM admin. We need to wrap === - asymmetric key (zone key) with symmetric key (master key) - symmetric key (master key) with asymmetric key (replica key) Can you please provide more info what purpose these keys have? I understand that the zone key is the DNSSEC asymmetric key for the zone. But what about the master key and replica key? Why the master key is symmetric and the replica asymmetric? LDAP schema prescribes some storage formats but my question is about crypto algorithms (and padding!) used for key wrapping. Asymmetric keys === According to schema [1] wrapped asymmetric (i.e. private) key must be stored in 'ipaPrivateKey' attribute as DER-encoded EncryptedPrivateKeyInfo structure according to RFC 5958 [2]. It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData part of EncryptedPrivateKeyInfo structure so we only have to add algorithm identifier, DER-encode the whole thing, and we could be done. I'm not sure where should I stick IV or what happens if default (fixed) IV value is left in place...? In general using fixed IV when encrypting multiple data (keys) with the same key breaks the security of the wrapped data. So no, fixed IV must not be used. Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with AES according to RFC 3394 (no padding) or RFC 5649 (with padding). RFC 3394 works only on blocks of 64 bits, which is not our case because EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get proper padding etc. And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but OpenSSL doesn't support RFC 5649! The patch with this functionality was submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state new and there was no reply to the e-mail in the original thread [4]. I am sorry, but this does not make much sense to me. Iff the SoftHSM's C_WrapKey is really safe wrapping method for backing up and/or replicating HSM's it must provide wrapped key in such format that the IV is pregenerated as part of the Wrap operation and stored in the final blob of wrapped key. Unfortunately I do not know much of SoftHSM. What do we do? - Convince OpenSSL to review and accept the patch? I would say the patch is not too useful as is - there are multiple problems with it such as it is not using proper high level interfaces for the AES encryption, etc. - Hack it around #0: Use something else as key wrapping method? Other wrapping methods would require SoftHSM modification because SoftHSM supports only AES mechanisms now. - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a downstream patch in SoftHSM? Do we have enough expertise to implement it correctly? - Hack it around #2: Implement raw key extraction from SoftHSM and do key wrapping somehow somewhere? (Please nooo.) Symmetric keys == should be stored in 'ipaSecretKey' attribute but detailed storage format definition is missing from schema [1] right now. Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with asymmetric key as *wrapping* key so we need to add this functionality. The first question is: What algorithm and padding scheme should we use? Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]? That would be relatively easy to implement to SoftHSM because it is
Re: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones
On 06/18/2014 01:46 PM, Martin Basti wrote:
On Wed, 2014-06-18 at 13:44 +0200, Martin Basti wrote:
On Fri, 2014-06-13 at 10:28 +0200, Martin Basti wrote:
Patches attached, require patches mbasti 0052-0055.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Rebased patches attached.
PEP8 fixes.
Sorry, patches are here
66.2:
1) Is it OK to just change constants in the update plugins?
-PRE_UPDATE = 1
-POST_UPDATE = 2
+PRE_SCHEMA_UPDATE = 1
+PRE_UPDATE = 2
+POST_UPDATE = 3
When people refer to the types via names, it should be OK. It just seemed
unnecessary to me.
67.2:
1) update_check_forwardzones:
I think we should set update_to_forward_zones to False when the objectclass is
there and add a check at the beginning of the execute to simply bail out, if
update_to_forward_zones is present in the sysupgrade file.
This will prevent the objectclass check (which takes some time) to run again
and again.
2) I would use different backup name:
+backup_filename = u'master-zones-transform-backup.ldif'
Probably something based on time so that different installations' backup do not
step on each other. You can inspire yourself in other backup files we create:
# ll /var/lib/ipa/backup/
total 16
drwx--. 2 root root 4096 May 30 08:10 ipa-full-2014-05-30-08-10-13
drwx--. 2 root root 4096 May 30 08:11 ipa-full-2014-05-30-08-11-09
drwx--. 2 root root 4096 May 30 08:13 ipa-full-2014-05-30-08-13-21
-rw-r--r--. 1 root root 3441 Jun 24 16:25 master-zones-transform-backup.ldif
3) This exception does not provide much information, we should at least log the
error message itself:
+except Exception:
+self.log.error('Unable to create backup file')
+return (False, False, [])
4) The actual upgrade failed in my case, when I had set forward policy:
# ipa-ldap-upgrade --upgrade
...
Updating managed permissions for user
Updating non-object managed permissions
Zones with specified forwarders with policy different than none will be
transformed to forward zones.
Original zones will be saved in LDIF format in
/var/lib/ipa/backup/master-zones-transform-backup.ldif file
No changes to ACI
Zone forward1.test. was sucessfully transformed to forward zone
Transform to forwardzone terminated: creating forwardzone forward2.test. failed
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py,
line 265, in execute
api.Command['dnsforwardzone_add'](zone['idnsname'][0], **kw)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 433, in
__call__
params = self.convert(**params)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 631, in
convert
(k, self.params[k].convert(v)) for (k, v) in kw.iteritems()
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 631, in
genexpr
(k, self.params[k].convert(v)) for (k, v) in kw.iteritems()
File /usr/lib/python2.7/site-packages/ipalib/parameters.py, line 797, in
convert
return self._convert_scalar(value)
File /usr/lib/python2.7/site-packages/ipalib/parameters.py, line 806, in
_convert_scalar
error=ugettext(self.type_error),
ConversionError: invalid 'idnsforwardpolicy': Gettext('incorrect type',
domain='ipa', localedir=None)
...
Attaching my DNS zone setting.
Martin
dn: idnsname=forward1.test.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=
com
idnsAllowDynUpdate: FALSE
idnsUpdatePolicy: grant IDM.LAB.ENG.BRQ.REDHAT.COM krb5-self * A; grant IDM.
LAB.ENG.BRQ.REDHAT.COM krb5-self * ; grant IDM.LAB.ENG.BRQ.REDHAT.COM k
rb5-self * SSHFP;
idnsallowquery: any;
idnsallowtransfer: none;
idnsforwarders: 10.0.0.1
idnsname: forward1.test.
idnssoaexpire: 1209600
idnssoaminimum: 3600
idnssoamname: vm-236.idm.lab.eng.brq.redhat.com.
idnssoarefresh: 3600
idnssoaretry: 900
idnssoarname: hostmaster.forward1.test.
idnssoaserial: 1403609417
idnszoneactive: TRUE
managedBy: cn=Manage DNS zone forward1.test.,cn=permissions,cn=pbac,dc=idm,d
c=lab,dc=eng,dc=brq,dc=redhat,dc=com
nsrecord: vm-236.idm.lab.eng.brq.redhat.com.
objectClass: idnszone
objectClass: top
objectClass: idnsrecord
objectClass: ipadnszone
dn: cn=Manage DNS zone forward1.test.,cn=permissions,cn=pbac,dc=idm,dc=lab,d
c=eng,dc=brq,dc=redhat,dc=com
cn: Manage DNS zone forward1.test.
ipaPermissionType: SYSTEM
objectClass: ipapermission
objectClass: top
objectClass: groupofnames
dn: idnsname=foo,idnsname=forward1.test.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,
dc=redhat,dc=com
arecord: 10.0.0.1
idnsname: foo
objectClass: top
objectClass: idnsrecord
dn: idnsname=forward2.test.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=
com
idnsAllowDynUpdate: FALSE
idnsUpdatePolicy: grant IDM.LAB.ENG.BRQ.REDHAT.COM krb5-self * A; grant IDM.
LAB.ENG.BRQ.REDHAT.COM krb5-self * ; grant IDM.LAB.ENG.BRQ.REDHAT.COM k
rb5-self * SSHFP;
idnsallowquery: any;
idnsallowtransfer: none;
Re: [Freeipa-devel] [PATCH] 670-675 webui: dns forward zones
On 24.6.2014 13:02, Petr Vobornik wrote:
ticket: https://fedorahosted.org/freeipa/ticket/4357
- patch 673 is compressed
- CI patches functionally depends on #667, #668
== PATCH] 670 webui: add confirmation for dns zone permission actions ==
All header actions should require confirmation.
== [PATCH] 671 webui: dns forward zones ==
Add DNS Forward Zones Web UI.
- pages under: Identity/DNS/DNS Forward Zones
== [PATCH] 672 webui-ci: dns forward zone tests ==
Selenium CI sanity tests for DNS Forward Zones
== [PATCH] 673 webui-test: static metadata update ==
Regular update of static metadata for testing and presentation purposes.
It should also contain new DNS Forward Zones metadata.
== [PATCH] 674 webui-test: dns forward zone json data ==
Fake API results for testing and presentation purposes of DNS Forward
Zones.
== [PATCH] 675 webui: fix detection of RPC command ==
old detection did not work with the static version used for test and
demonstration purposes.
Attaching an updated version of #675 with a fix for unit tests. Btw I'm
not very satisfied with patch #675's approach. I'm open to suggestions
for better approaches.
--
Petr Vobornik
From d39c27e9aeb85bdae0f10a3bf16a5d8aca42b4ff Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Wed, 18 Jun 2014 18:59:44 +0200
Subject: [PATCH] webui: fix detection of RPC command
old detection did not work with the static version used for test and
demonstration purposes.
https://fedorahosted.org/freeipa/ticket/4357
---
install/ui/src/freeipa/field.js | 4 ++--
install/ui/test/aci_tests.js| 16
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/install/ui/src/freeipa/field.js b/install/ui/src/freeipa/field.js
index 1ae3ddf3ee98493426a1776f8a315206c5a0f8f6..0bc8c6f5eb633463ca829b0e46a0fbc0ffacefd7 100644
--- a/install/ui/src/freeipa/field.js
+++ b/install/ui/src/freeipa/field.js
@@ -775,8 +775,8 @@ field.Adapter = declare(null, {
get_record: function(data) {
// detection if it's result or raw RPC command response
-// all raw responses should contain `version` and `principal`
-if (!data.version || !data.principal) {
+// each RPC response should define properties as follows
+if (data.id === undefined || data.result === undefined || data.error === undefined) {
return data;
}
diff --git a/install/ui/test/aci_tests.js b/install/ui/test/aci_tests.js
index e82dd86df1f61ad98413492d687d14d4c73a9e79..1cfc2fb4fa059b464928a2c5cc25972e1d19c907 100644
--- a/install/ui/test/aci_tests.js
+++ b/install/ui/test/aci_tests.js
@@ -229,10 +229,10 @@ var get_visible_rows = function(section) {
test(Testing type target., function() {
-var data = {};
-data.result = {};
-data.result.result = {
-type: 'hostgroup'
+var data = {
+id: null,
+error: null,
+result: { result: { type: 'hostgroup'} }
};
target_facet.load(data);
@@ -266,10 +266,10 @@ test(Testing type target., function() {
test(Testing general target., function() {
-var data = {};
-data.result = {};
-data.result.result = {
-extratargetfilter: 'somevalue'
+var data = {
+id: null,
+error: null,
+result: { result: { extratargetfilter: 'hostgroup'} }
};
target_facet.load(data);
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0269] Silence GCC warning about uninitialized ldap_writeback
Hello, Silence GCC warning about uninitialized ldap_writeback. It seems like false positive, I can't imagine how ldap_writeback could be used without prior initialization. -- Petr^2 Spacek From eb253b58d6214b3f94d22c3ec2dcf62d0103ad46 Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Mon, 23 Jun 2014 17:02:08 +0200 Subject: [PATCH] Silence GCC warning about uninitialized ldap_writeback. Signed-off-by: Petr Spacek pspa...@redhat.com --- src/ldap_helper.c | 4 1 file changed, 4 insertions(+) diff --git a/src/ldap_helper.c b/src/ldap_helper.c index 43bacf779f44a709b0cefd638826633b9d2d8891..a7a782fdfc5ae4d28b50155c9614d66a427dc3e0 100644 --- a/src/ldap_helper.c +++ b/src/ldap_helper.c @@ -2130,7 +2130,11 @@ zone_sync_apex(const ldap_instance_t * const inst, isc_boolean_t soa_tuple_alloc = ISC_FALSE; isc_uint32_t curr_serial; + REQUIRE(ldap_writeback != NULL); + INIT_LIST(rdatalist); + *ldap_writeback = ISC_FALSE; /* GCC */ + CHECK(setting_get_str(fake_mname, inst-local_settings, fake_mname)); CHECK(ldap_parse_rrentry(inst-mctx, entry, name, fake_mname, -- 1.9.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones
On Tue, 2014-06-24 at 16:36 +0200, Martin Kosek wrote:
On 06/18/2014 01:46 PM, Martin Basti wrote:
On Wed, 2014-06-18 at 13:44 +0200, Martin Basti wrote:
On Fri, 2014-06-13 at 10:28 +0200, Martin Basti wrote:
Patches attached, require patches mbasti 0052-0055.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Rebased patches attached.
PEP8 fixes.
Sorry, patches are here
66.2:
1) Is it OK to just change constants in the update plugins?
-PRE_UPDATE = 1
-POST_UPDATE = 2
+PRE_SCHEMA_UPDATE = 1
+PRE_UPDATE = 2
+POST_UPDATE = 3
When people refer to the types via names, it should be OK. It just seemed
unnecessary to me.
I checked where the constants are used, and it shouldn't broke anything.
It looks weird to me to have something which happens first with last
number.
Should I set PRE_SCHEMA_UPDATE = 3 and leave other unchanged then?
67.2:
1) update_check_forwardzones:
I think we should set update_to_forward_zones to False when the objectclass is
there and add a check at the beginning of the execute to simply bail out, if
update_to_forward_zones is present in the sysupgrade file.
This will prevent the objectclass check (which takes some time) to run again
and again.
Good point thanks.
2) I would use different backup name:
+backup_filename = u'master-zones-transform-backup.ldif'
Probably something based on time so that different installations' backup do
not
step on each other. You can inspire yourself in other backup files we create:
# ll /var/lib/ipa/backup/
total 16
drwx--. 2 root root 4096 May 30 08:10 ipa-full-2014-05-30-08-10-13
drwx--. 2 root root 4096 May 30 08:11 ipa-full-2014-05-30-08-11-09
drwx--. 2 root root 4096 May 30 08:13 ipa-full-2014-05-30-08-13-21
-rw-r--r--. 1 root root 3441 Jun 24 16:25 master-zones-transform-backup.ldif
Is this better: forward-zones-transform-%datetime%.ldif ?
3) This exception does not provide much information, we should at least log
the
error message itself:
+except Exception:
+self.log.error('Unable to create backup file')
+return (False, False, [])
Sorry my bad, I missed that
4) The actual upgrade failed in my case, when I had set forward policy:
# ipa-ldap-upgrade --upgrade
...
Updating managed permissions for user
Updating non-object managed permissions
Zones with specified forwarders with policy different than none will be
transformed to forward zones.
Original zones will be saved in LDIF format in
/var/lib/ipa/backup/master-zones-transform-backup.ldif file
No changes to ACI
Zone forward1.test. was sucessfully transformed to forward zone
Transform to forwardzone terminated: creating forwardzone forward2.test.
failed
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py,
line 265, in execute
api.Command['dnsforwardzone_add'](zone['idnsname'][0], **kw)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 433, in
__call__
params = self.convert(**params)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 631, in
convert
(k, self.params[k].convert(v)) for (k, v) in kw.iteritems()
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 631, in
genexpr
(k, self.params[k].convert(v)) for (k, v) in kw.iteritems()
File /usr/lib/python2.7/site-packages/ipalib/parameters.py, line 797, in
convert
return self._convert_scalar(value)
File /usr/lib/python2.7/site-packages/ipalib/parameters.py, line 806, in
_convert_scalar
error=ugettext(self.type_error),
ConversionError: invalid 'idnsforwardpolicy': Gettext('incorrect type',
domain='ipa', localedir=None)
...
Attaching my DNS zone setting.
I will inspect it.
Martin
Thank you for review
--
Martin^2 Basti
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0270-0271] Add TLSA and DLV RR types to LDAP schema
Hello, Add TLSA and DLV RR types to LDAP schema. Those RR types will be handy for DNSSEC users. -- Petr^2 Spacek From eae0035df2a510512844f602acc70c096fcde2b4 Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Mon, 23 Jun 2014 17:20:46 +0200 Subject: [PATCH] Add DLV RR type to LDAP schema. https://fedorahosted.org/bind-dyndb-ldap/ticket/56 Signed-off-by: Petr Spacek pspa...@redhat.com --- doc/schema | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/doc/schema b/doc/schema index 9651fe154d01d39ed5874fb45792b4fab8c67340..2325ee3e50636fd6a491eeb5d851acb1e6bdb98d 100644 --- a/doc/schema +++ b/doc/schema @@ -160,6 +160,13 @@ attributetype ( 1.3.6.1.4.1.2428.20.1.51 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) +attributetype ( 1.3.6.1.4.1.2428.20.1.32769 + NAME 'DLVRecord' + DESC 'RFC 4431: DNSSEC Lookaside Validation' + EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + attributetype ( 2.16.840.1.113730.3.8.5.0 NAME 'idnsName' DESC 'DNS FQDN' @@ -295,7 +302,7 @@ objectclass ( 2.16.840.1.113730.3.8.6.0 SRVRecord $ TXTRecord $ MXRecord $ MDRecord $ HINFORecord $ MINFORecord $ AFSDBRecord $ LOCRecord $ NXTRecord $ NAPTRRecord $ KXRecord $ CERTRecord $ DNAMERecord $ - DSRecord $ SSHFPRecord + DSRecord $ SSHFPRecord $ DLVRecord ) ) objectclass ( 2.16.840.1.113730.3.8.6.1 -- 1.9.3 From 174190a582825478a555c722e9e0314770b895a5 Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Tue, 24 Jun 2014 16:41:12 +0200 Subject: [PATCH] Add TLSA RR type to LDAP schema. https://fedorahosted.org/bind-dyndb-ldap/ticket/94 Signed-off-by: Petr Spacek pspa...@redhat.com --- doc/schema | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/schema b/doc/schema index 2325ee3e50636fd6a491eeb5d851acb1e6bdb98d..73e8ee9d5fafd89b136b3f3cf248bfd23c91179c 100644 --- a/doc/schema +++ b/doc/schema @@ -160,6 +160,12 @@ attributetype ( 1.3.6.1.4.1.2428.20.1.51 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) +attributetype ( 1.3.6.1.4.1.2428.20.1.52 NAME 'TLSARecord' +DESC 'DNS-Based Authentication of Named Entities - Transport Layer Security Protocol, RFC 6698' +EQUALITY caseIgnoreIA5Match +SUBSTR caseIgnoreIA5SubstringsMatch +SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + attributetype ( 1.3.6.1.4.1.2428.20.1.32769 NAME 'DLVRecord' DESC 'RFC 4431: DNSSEC Lookaside Validation' -- 1.9.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0273-0274] Bump NVR to 5.0Update README and NEWS: DNSSEC and changes in forwarding semantics
Hello, it's release time! Bump NVR to 5.0 and update README and NEWS to describe DNSSEC support and changes in forwarding semantics. -- Petr^2 Spacek From d093af67072e44ce65be04c7267c4dbaa6cadf08 Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Tue, 24 Jun 2014 16:14:28 +0200 Subject: [PATCH] Update README and NEWS: DNSSEC and changes in forwarding semantics. https://fedorahosted.org/bind-dyndb-ldap/ticket/56 https://fedorahosted.org/bind-dyndb-ldap/ticket/99 Signed-off-by: Petr Spacek pspa...@redhat.com --- NEWS | 14 README | 121 ++--- 2 files changed, 122 insertions(+), 13 deletions(-) diff --git a/NEWS b/NEWS index edfe8d71298843d1e9380a49baa49d86a52a8481..970ab7781d4775a499bded3c0299a759f4630f74 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,17 @@ +5.0 + +[1] Support for DNSSEC in-line signing was added. Now any LDAP zone can be +signed with keys provided by user. + +[2] DNSKEY, RRSIG, NSEC and NSEC3 records are automatically managed +by BIND+bind-dyndb-ldap. Respective attributes in LDAP are ignored. + +[3] Forwarder semantic was changed to match BIND's semantic: +- idnsZone object always represent master zone +- idnsForwardZone object (new) always represent forward zone + +[4] Master root zone can be stored in LDAP. + 4.4 [1] Error handling for zone loading was fixed. diff --git a/README b/README index b2c3653ef3ae653e4454ec43e341a220a4968e8f..4e3082b3b6fd6d7f8abcdb9f4c0803569eb0f896 100644 --- a/README +++ b/README @@ -10,16 +10,17 @@ for your version here: Hopefully, the patch will once be included in the official BIND release. -Because of bug in dns_db_unregister() in older BIND versions, BIND = 9.7.0a1 -is required. +BIND = 9.9.0 is required. 2. Features === + * support for dynamic updates * SASL authentication * SyncRepl (RFC 4533) for run-time synchronization with LDAP server * read-query performance nearly same as with plain BIND * AXFR and IXFR zone transfers are supported +* DNSSEC in-line signing is supported, including dynamic updates 3. Installation @@ -51,9 +52,11 @@ This will install the file ldap.so into the libdir/bind/ directory. You can find the complete LDAP schema in the documentation directory. An example zone ldif is available in the doc directory. -4.1 Zone (idnsZone) attributes --- +4.1 Master zone (idnsZone) +-- +Object class idnsZone is equivalent to type master statement in named.conf. +Attributes: * idnsAllowDynUpdate Allow dynamic update of records in this zone. If attribute doesn't exist, value dyn_update from plugin configuration will be used. @@ -94,24 +97,46 @@ example zone ldif is available in the doc directory. i.e. effectively disables forwarding and ignores idnsForwarders attribute. - Value none disables forwarding for given zone and ignores - global forwarders. Zone with forward policy none is considered - as type master, not forward. Values first and only are relevant in conjunction with a valid idnsForwarders attribute. Their meaning is same as in BIND9. * idnsForwarders - Defines multiple IP addresses to which queries will be forwarded and - effectively creates forward zones. + Defines multiple IP addresses to which recursive queries will be + forwarded. This is equivalent to forwarders statement in master + zone configuration. + + I.e. local BIND replies authoritatively to queries when possible + (including authoritative NXDOMAIN answers) so forwarding affects only + queries made by BIND to answer recursive queries which cannot be + answered locally. Please see + https://lists.isc.org/pipermail/bind-users/2006-January/060810.html + https://lists.isc.org/pipermail/bind-users/2011-March/083244.html + It is multi-value attribute: Each IP address (and optional port) has to be in own value. BIND9 syntax for forwarders is required. Optional port can be specified by adding port number after IP address. IPv4 and IPv6 addresses are supported. Examples: 1.2.3.4 or 1.2.3.4 port 553 or A::B or A::B port 553 - Zones with idnsForwarders attribute specified and forward policy other - than none are considered as forward zones. All records in LDAP - belonging to those zones are ignored and all queries are forwarded. +* idnsName + Absolute name of DNS zone. It is recommended to use names with trailing + period, e.g. example.com. + +* idnsSecInlineSigning (default FALSE) + DNSSEC in-line signing configuration. Value TRUE is equivalent to + following zone configuration in named.conf (default BIND values): + + auto-dnssec maintain; + sig-validity-interval 2592000; # 30 days + # re-sign interval will be 648000 seconds = 7.5 days + sig-signing-signatures 10; + sig-signing-nodes 10; + sig-signing-type 65534; + update-check-ksk yes; + dnssec-loadkeys-interval 60; # minutes + key-directory plugin-instance-dir/zone-name/keys; + + There is no way
Re: [Freeipa-devel] [PATCH 0267-0268] Preparation for 4.4 release
On 23.6.2014 17:12, Petr Spacek wrote: Hello, Bump NVR to 4.4. Update NEWS for upcoming 4.4 release. Pushed to master: 2cd574e90a9fdebdbeaab45ef335e7d63e85dfd7 3a705963ed575f01b792a7e89d825cf56ce99734 At this point v4 branches from master. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 677 webui: support unlock user command
Call user-unlock command from Web UI.
It will unlock displayed user on current master.
related to:
https://fedorahosted.org/freeipa/ticket/2792
--
Petr Vobornik
From 1d39ac323d3c5975a6725bac50c81f655606f9b2 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 24 Jun 2014 12:24:23 +0200
Subject: [PATCH] webui: support unlock user command
Call user-unlock command from Web UI.
It will unlock displayed user on current master.
related to:
https://fedorahosted.org/freeipa/ticket/2792
---
install/ui/src/freeipa/user.js | 10 +-
install/ui/test/data/ipa_init.json | 4 +++-
ipalib/plugins/internal.py | 2 ++
ipatests/test_webui/test_user.py | 2 ++
4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/install/ui/src/freeipa/user.js b/install/ui/src/freeipa/user.js
index 3685b116aad6708f88a437a4abebc68ff9df4474..50eaca17f6536061718bde9ca26e1c76c6e38e56 100644
--- a/install/ui/src/freeipa/user.js
+++ b/install/ui/src/freeipa/user.js
@@ -268,12 +268,20 @@ return {
'delete',
'reset_password',
{
+$factory: IPA.object_action,
+name: 'unlock',
+method: 'unlock',
+label: '@i18n:objects.user.unlock',
+needs_confirm: true,
+confirm_msg: '@i18n:objects.user.unlock_confirm'
+},
+{
$type: 'automember_rebuild',
name: 'automember_rebuild',
label: '@i18n:actions.automember_rebuild'
}
],
-header_actions: ['reset_password', 'enable', 'disable', 'delete', 'automember_rebuild'],
+header_actions: ['reset_password', 'enable', 'disable', 'delete', 'unlock', 'automember_rebuild'],
state: {
evaluators: [
{
diff --git a/install/ui/test/data/ipa_init.json b/install/ui/test/data/ipa_init.json
index c678d0315c3e92a54dc63f2bd4aef1c90ce68185..79aff6ded21bf43f1089ad4ee1f58b051c64d54a 100644
--- a/install/ui/test/data/ipa_init.json
+++ b/install/ui/test/data/ipa_init.json
@@ -499,7 +499,9 @@
mailing: Mailing Address,
misc: Misc. Information,
status_confirmation: Are you sure you want to ${action} the user?br/The change will take effect immediately.,
-status_link: Click to ${action}
+status_link: Click to ${action},
+unlock: Unlock,
+unlock_confirm: Are you sure you want to unlock user ${object}?
}
},
password: {
diff --git a/ipalib/plugins/internal.py b/ipalib/plugins/internal.py
index 57782c207a27e9b2c8ba83a54eb3cd4b20719f9e..6c322da51754a9c0f8bb6e4510a81ef7fa328f4c 100644
--- a/ipalib/plugins/internal.py
+++ b/ipalib/plugins/internal.py
@@ -645,6 +645,8 @@ class i18n_messages(Command):
misc: _(Misc. Information),
status_confirmation: _(Are you sure you want to ${action} the user?br/The change will take effect immediately.),
status_link: _(Click to ${action}),
+unlock: _(Unlock),
+unlock_confirm: _(Are you sure you want to unlock user ${object}?),
},
},
password: {
diff --git a/ipatests/test_webui/test_user.py b/ipatests/test_webui/test_user.py
index 766fdafb4ee700fc2a4131dbf92d694be8d17188..d6d7ced8d52d5509a837874a0bec50bdc39f0fab 100644
--- a/ipatests/test_webui/test_user.py
+++ b/ipatests/test_webui/test_user.py
@@ -156,6 +156,8 @@ class test_user(UI_driver):
self.reset_password_action(pwd)
self.assert_text_field('has_password', '**')
+self.action_list_action('unlock')
+
# delete
self.delete_action(user.ENTITY, user.PKEY)
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0269] Silence GCC warning about uninitialized ldap_writeback
On (24/06/14 16:46), Petr Spacek wrote: Hello, Silence GCC warning about uninitialized ldap_writeback. It seems like false positive, I can't imagine how ldap_writeback could be used without prior initialization. -- Petr^2 Spacek From eb253b58d6214b3f94d22c3ec2dcf62d0103ad46 Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Mon, 23 Jun 2014 17:02:08 +0200 Subject: [PATCH] Silence GCC warning about uninitialized ldap_writeback. Signed-off-by: Petr Spacek pspa...@redhat.com --- src/ldap_helper.c | 4 1 file changed, 4 insertions(+) diff --git a/src/ldap_helper.c b/src/ldap_helper.c index 43bacf779f44a709b0cefd638826633b9d2d8891..a7a782fdfc5ae4d28b50155c9614d66a427dc3e0 100644 --- a/src/ldap_helper.c +++ b/src/ldap_helper.c @@ -2130,7 +2130,11 @@ zone_sync_apex(const ldap_instance_t * const inst, isc_boolean_t soa_tuple_alloc = ISC_FALSE; isc_uint32_t curr_serial; + REQUIRE(ldap_writeback != NULL); + INIT_LIST(rdatalist); + *ldap_writeback = ISC_FALSE; /* GCC */ + CHECK(setting_get_str(fake_mname, inst-local_settings, fake_mname)); CHECK(ldap_parse_rrentry(inst-mctx, entry, name, fake_mname, -- 1.9.3 ACK LS ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command
On Tue, 2014-06-24 at 19:34 +0300, Alexander Bokovoy wrote:
On Tue, 24 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote:
On Tue, 03 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote:
On 3.6.2014 05:08, Nathaniel McCallum wrote:
This command calls the token sync HTTP POST call in the server
providing
the CLI interface to synchronization.
https://fedorahosted.org/freeipa/ticket/4260
This patch depends on my patch #0055.
Build fails on validation. You forgot to update API.txt and also the
command misses __doc__.
(not a proper review)
Failed for me:
[root@ipa-01 rpms]# ipa otptoken-show test.token
Unique ID: test.token
Description: test token
Owner: abbra
Vendor: FreeIPA
Model: hotp
[root@ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token
Password:
First Code:
Second Code:
ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized',
httplib.HTTPMessage instance at 0x2cdde60)
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 129,
in execute
result = self.Command[_name](*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439,
in __call__
ret = self.run(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 1118,
in run
return self.forward(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py,
line 427, in forward
rsp = urllib.urlopen(sync_uri, query)
File /usr/lib64/python2.7/urllib.py, line 89, in urlopen
return opener.open(url, data)
File /usr/lib64/python2.7/urllib.py, line 210, in open
return getattr(self, name)(url, data)
File /usr/lib64/python2.7/urllib.py, line 454, in open_https
data)
File /usr/lib64/python2.7/urllib.py, line 374, in http_error
result = method(url, fp, errcode, errmsg, headers, data)
File /usr/lib64/python2.7/urllib.py, line 689, in http_error_401
errcode, errmsg, headers)
File /usr/lib64/python2.7/urllib.py, line 381, in http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 401, 'Unauthorized', httplib.HTTPMessage instance
at 0x2cdde60)
ipa: ERROR: an internal error has occurred
Note that I can successfully use the token. It looks like authentication
with urllib.urlopen(sync_uri, query) fails.
Works for me (just tested). I suspect you have not updated the ipa httpd
config. Did you apply patches 0054, 0055 and 0056?
Yes, I did apply those patches and I installed packages as an upgrade.
How I supposed to update httpd config? I think we need to solve this
without re-install and it should be done automatically.
Oh. I thought it *was* done automatically...
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] User Life Cycle: scoping of referential integrity, memberof, IPA UUID plugins
Hello, User life cycle assigns a status to user entries depending where they are in the DIT. 'Active' user will be under 'cn=accounts,SUFFIX' while 'Stage' and 'Delete' users are somewhere under 'cn=provisioning,SUFFIX'. Only 'Active' users have valid membership attributes: A Stage/Delete user does not belong to any 'Active' group. membership is managed by DS plugins, and particularly RI and memberof. To automatically update membership attributes RI and memberof implement a scoping, that update/add/remove membership attributes if the group/user are Active. The scoping is a single valued attribute. It create failures in IPA tests if I restrict RI/memberof to 'cn=accounts,SUFFIX'. For example adding a host (under 'cn=accounts,SUFFIX) adds it to a network group that is under 'cn=alt,SUFFIX'. A solution would be that the attribute that scopes the plugin is multivalued. But then it would require a long list of values: cn=pbac,SUFFIX cn=hbac,SUFFX cn=alt,SUFFIX cn=accounts, SUFFIX ... An other solution would be to exclude some parts of the DIT, here limited to 'cn=provisionning,SUFFIX'. (prefered solution). This is a similar issue with IPA UUID plugin that generates ipaUniqueID for entries under 'cn=accounts' but also 'cn=alt' or 'cn=hbac'. regards thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command
On Tue, 24 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote:
On Tue, 03 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote:
On 3.6.2014 05:08, Nathaniel McCallum wrote:
This command calls the token sync HTTP POST call in the server providing
the CLI interface to synchronization.
https://fedorahosted.org/freeipa/ticket/4260
This patch depends on my patch #0055.
Build fails on validation. You forgot to update API.txt and also the
command misses __doc__.
(not a proper review)
Failed for me:
[root@ipa-01 rpms]# ipa otptoken-show test.token
Unique ID: test.token
Description: test token
Owner: abbra
Vendor: FreeIPA
Model: hotp
[root@ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token
Password:
First Code:
Second Code:
ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized',
httplib.HTTPMessage instance at 0x2cdde60)
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 129,
in execute
result = self.Command[_name](*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439,
in __call__
ret = self.run(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 1118,
in run
return self.forward(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py,
line 427, in forward
rsp = urllib.urlopen(sync_uri, query)
File /usr/lib64/python2.7/urllib.py, line 89, in urlopen
return opener.open(url, data)
File /usr/lib64/python2.7/urllib.py, line 210, in open
return getattr(self, name)(url, data)
File /usr/lib64/python2.7/urllib.py, line 454, in open_https
data)
File /usr/lib64/python2.7/urllib.py, line 374, in http_error
result = method(url, fp, errcode, errmsg, headers, data)
File /usr/lib64/python2.7/urllib.py, line 689, in http_error_401
errcode, errmsg, headers)
File /usr/lib64/python2.7/urllib.py, line 381, in http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 401, 'Unauthorized', httplib.HTTPMessage instance at
0x2cdde60)
ipa: ERROR: an internal error has occurred
Note that I can successfully use the token. It looks like authentication
with urllib.urlopen(sync_uri, query) fails.
Works for me (just tested). I suspect you have not updated the ipa httpd
config. Did you apply patches 0054, 0055 and 0056?
Yes, I did apply those patches and I installed packages as an upgrade.
How I supposed to update httpd config? I think we need to solve this
without re-install and it should be done automatically.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command
On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote:
On Tue, 03 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote:
On 3.6.2014 05:08, Nathaniel McCallum wrote:
This command calls the token sync HTTP POST call in the server providing
the CLI interface to synchronization.
https://fedorahosted.org/freeipa/ticket/4260
This patch depends on my patch #0055.
Build fails on validation. You forgot to update API.txt and also the
command misses __doc__.
(not a proper review)
Failed for me:
[root@ipa-01 rpms]# ipa otptoken-show test.token
Unique ID: test.token
Description: test token
Owner: abbra
Vendor: FreeIPA
Model: hotp
[root@ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token
Password:
First Code:
Second Code:
ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized',
httplib.HTTPMessage instance at 0x2cdde60)
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 129,
in execute
result = self.Command[_name](*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439,
in __call__
ret = self.run(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 1118,
in run
return self.forward(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py,
line 427, in forward
rsp = urllib.urlopen(sync_uri, query)
File /usr/lib64/python2.7/urllib.py, line 89, in urlopen
return opener.open(url, data)
File /usr/lib64/python2.7/urllib.py, line 210, in open
return getattr(self, name)(url, data)
File /usr/lib64/python2.7/urllib.py, line 454, in open_https
data)
File /usr/lib64/python2.7/urllib.py, line 374, in http_error
result = method(url, fp, errcode, errmsg, headers, data)
File /usr/lib64/python2.7/urllib.py, line 689, in http_error_401
errcode, errmsg, headers)
File /usr/lib64/python2.7/urllib.py, line 381, in http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 401, 'Unauthorized', httplib.HTTPMessage instance at
0x2cdde60)
ipa: ERROR: an internal error has occurred
Note that I can successfully use the token. It looks like authentication
with urllib.urlopen(sync_uri, query) fails.
Works for me (just tested). I suspect you have not updated the ipa httpd
config. Did you apply patches 0054, 0055 and 0056?
Nathaniel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command
On Tue, 24 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-24 at 19:34 +0300, Alexander Bokovoy wrote:
On Tue, 24 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote:
On Tue, 03 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote:
On 3.6.2014 05:08, Nathaniel McCallum wrote:
This command calls the token sync HTTP POST call in the server providing
the CLI interface to synchronization.
https://fedorahosted.org/freeipa/ticket/4260
This patch depends on my patch #0055.
Build fails on validation. You forgot to update API.txt and also the
command misses __doc__.
(not a proper review)
Failed for me:
[root@ipa-01 rpms]# ipa otptoken-show test.token
Unique ID: test.token
Description: test token
Owner: abbra
Vendor: FreeIPA
Model: hotp
[root@ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token
Password:
First Code:
Second Code:
ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized',
httplib.HTTPMessage instance at 0x2cdde60)
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 129,
in execute
result = self.Command[_name](*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439,
in __call__
ret = self.run(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 1118,
in run
return self.forward(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py,
line 427, in forward
rsp = urllib.urlopen(sync_uri, query)
File /usr/lib64/python2.7/urllib.py, line 89, in urlopen
return opener.open(url, data)
File /usr/lib64/python2.7/urllib.py, line 210, in open
return getattr(self, name)(url, data)
File /usr/lib64/python2.7/urllib.py, line 454, in open_https
data)
File /usr/lib64/python2.7/urllib.py, line 374, in http_error
result = method(url, fp, errcode, errmsg, headers, data)
File /usr/lib64/python2.7/urllib.py, line 689, in http_error_401
errcode, errmsg, headers)
File /usr/lib64/python2.7/urllib.py, line 381, in http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 401, 'Unauthorized', httplib.HTTPMessage instance at
0x2cdde60)
ipa: ERROR: an internal error has occurred
Note that I can successfully use the token. It looks like authentication
with urllib.urlopen(sync_uri, query) fails.
Works for me (just tested). I suspect you have not updated the ipa httpd
config. Did you apply patches 0054, 0055 and 0056?
Yes, I did apply those patches and I installed packages as an upgrade.
How I supposed to update httpd config? I think we need to solve this
without re-install and it should be done automatically.
Oh. I thought it *was* done automatically...
No. You only modified the template which is used for an install from
scratch.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Design Review Keytab Retrieval
- Original Message -
On Fri, 2014-06-20 at 16:05 -0400, Simo Sorce wrote:
On Fri, 2014-06-20 at 14:47 -0400, Nathaniel McCallum wrote:
This change would have very small impact on your patch set, but would
be
much clearer for the future consumers of this protocol. Code can be
changed; protocols can't.
Ok this new patchset implements the requested change.
Initial testing seem to indicate it all works as expected.
0001: Line 555 has very wrong indentation.
Attached a new patch 0001 hat fixes this.
Simo.From 214d1e167f9c9ea687f219ef74162e557ae496b0 Mon Sep 17 00:00:00 2001
From: Simo Sorce s...@redhat.com
Date: Tue, 17 Sep 2013 00:25:14 -0400
Subject: [PATCH 1/6] keytabs: Modularize setkeytab operation
In preparation of adding another function to avoid code duplication.
Related:
https://fedorahosted.org/freeipa/ticket/3859
---
.../ipa-pwd-extop/ipa_pwd_extop.c | 1112 +++-
1 file changed, 623 insertions(+), 489 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
index d8af3915300384933e621ffe8adea8904588985d..2648a53703fc6766bd2e29b830ea034fb519beff 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
@@ -93,8 +93,8 @@ void *ipapwd_get_plugin_id(void)
return ipapwd_plugin_id;
}
-static int filter_keys(struct ipapwd_krbcfg *krbcfg,
- struct ipapwd_keyset *kset)
+static void filter_keys(struct ipapwd_krbcfg *krbcfg,
+struct ipapwd_keyset *kset)
{
int i, j;
@@ -123,8 +123,6 @@ static int filter_keys(struct ipapwd_krbcfg *krbcfg,
i--;
}
}
-
-return 0;
}
static int ipapwd_to_ldap_pwpolicy_error(int ipapwderr)
@@ -562,49 +560,570 @@ free_and_return:
}
+static char *check_service_name(krb5_context krbctx, char *svc)
+{
+krb5_principal krbname = NULL;
+krb5_error_code krberr;
+char *name = NULL;
+
+krberr = krb5_parse_name(krbctx, svc, krbname);
+if (krberr) {
+LOG_FATAL(krb5_parse_name failed\n);
+} else {
+/* invert so that we get the canonical form (add REALM if not present
+ * for example) */
+krberr = krb5_unparse_name(krbctx, krbname, name);
+if (krberr) {
+LOG_FATAL(krb5_unparse_name failed\n);
+}
+}
+
+krb5_free_principal(krbctx, krbname);
+return name;
+}
+
+static Slapi_Backend *get_realm_backend(void)
+{
+Slapi_Backend *be;
+Slapi_DN *sdn;
+
+sdn = slapi_sdn_new_dn_byval(ipa_realm_dn);
+if (!sdn) return NULL;
+be = slapi_be_select(sdn);
+slapi_sdn_free(sdn);
+return be;
+}
+
+static const char *get_realm_base_dn(void)
+{
+const Slapi_DN *bsdn;
+Slapi_Backend *be;
+
+/* Find ancestor base DN */
+be = get_realm_backend();
+if (!be) return NULL;
+
+bsdn = slapi_be_getsuffix(be, 0);
+if (!bsdn) return NULL;
+
+return slapi_sdn_get_dn(bsdn);
+}
+
+static Slapi_Entry *get_entry_by_principal(const char *principal)
+{
+const char *bdn;
+char *filter = NULL;
+Slapi_PBlock *pb = NULL;
+char *attrlist[] = { krbPrincipalKey, krbLastPwdChange,
+ userPassword, krbPrincipalName,
+ enrolledBy, NULL };
+Slapi_Entry **es = NULL;
+int res, ret, i;
+Slapi_Entry *entry = NULL;
+
+/* Find ancestor base DN */
+bdn = get_realm_base_dn();
+if (!bdn) {
+LOG_TRACE(Search for Base DN failed\n);
+goto free_and_return;
+}
+
+filter = slapi_ch_smprintf((krbPrincipalName=%s), principal);
+if (!filter) {
+LOG_TRACE(Building filter failed\n);
+goto free_and_return;
+}
+
+pb = slapi_pblock_new();
+slapi_search_internal_set_pb(pb, bdn, LDAP_SCOPE_SUBTREE, filter,
+ attrlist, 0,
+ NULL, /* Controls */ NULL, /* UniqueID */
+ ipapwd_plugin_id, 0); /* Flags */
+
+/* do search the tree */
+ret = slapi_search_internal_pb(pb);
+slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_RESULT, res);
+if (ret == -1 || res != LDAP_SUCCESS) {
+LOG_TRACE(Search for Principal failed, err (%d)\n, res ? res : ret);
+goto free_and_return;
+}
+
+/* get entries */
+slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, es);
+if (!es) {
+LOG_TRACE(No entries ?!);
+goto free_and_return;
+}
+
+/* count entries */
+for (i = 0; es[i]; i++) /* count */ ;
+
+/* if there is none or more than one, freak out */
+if (i != 1) {
+LOG_TRACE(Too many entries, or entry no found (%d), i);
+goto free_and_return;
+}
+entry = slapi_entry_dup(es[0]);
+
+free_and_return:
+if (pb) {
+slapi_free_search_results_internal(pb);
+slapi_pblock_destroy(pb);
+
Re: [Freeipa-devel] [PATCH 0233] trusts: Add more read attributes
Attaching patch 234, which resolves another ACI issue related to trusts.
On 06/24/2014 02:50 PM, Tomas Babej wrote:
Hi,
this is a follow up patch for 232. Read access to additional attributes
is required for the trust objects.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
--
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 629dc5ba07ef9490ba7dbce33306b02c3494893d Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Tue, 24 Jun 2014 18:24:32 +0200
Subject: [PATCH] trusts: Allow reading system trust accounts by adtrust agents
---
ACI.txt | 2 ++
install/updates/60-trusts.update | 8
ipalib/plugins/trust.py | 11 +++
3 files changed, 21 insertions(+)
diff --git a/ACI.txt b/ACI.txt
index 0398a52fcf2639f895f6bb7cd8bd91412affa6d3..94e3f2850d84c3819772504e21b44246306c6be8 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -112,6 +112,8 @@ dn: cn=System: Read Sudoers compat tree,cn=permissions,cn=pbac,dc=ipa,dc=example
aci: (targetattr = cn || description || objectclass || ou || sudocommand || sudohost || sudonotafter || sudonotbefore || sudooption || sudoorder || sudorunas || sudorunasgroup || sudorunasuser || sudouser)(target = ldap:///ou=sudoers,dc=ipa,dc=example;)(version 3.0;acl permission:System: Read Sudoers compat tree;allow (compare,read,search) userdn = ldap:///all;;)
dn: cn=System: Read Trust Information,cn=permissions,cn=pbac,dc=ipa,dc=example
aci: (targetattr = cn || ipantflatname || ipantsecurityidentifier || ipantsidblacklistincoming || ipantsidblacklistoutgoing || ipanttrusteddomainsid || ipanttrustpartner || objectclass)(version 3.0;acl permission:System: Read Trust Information;allow (compare,read,search) userdn = ldap:///all;;)
+dn: cn=System: Read system trust accounts,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetattr = gidnumber || uidnumber)(version 3.0;acl permission:System: Read system trust accounts;allow (compare,read,search) groupdn = ldap:///cn=System: Read system trust accounts,cn=permissions,cn=pbac,dc=ipa,dc=example;)
dn: cn=System: Add User to default group,cn=permissions,cn=pbac,dc=ipa,dc=example
aci: (targetattr = member)(target = ldap:///cn=ipausers,cn=groups,cn=accounts,dc=ipa,dc=example;)(version 3.0;acl permission:System: Add User to default group;allow (write) groupdn = ldap:///cn=System: Add User to default group,cn=permissions,cn=pbac,dc=ipa,dc=example;)
dn: cn=System: Add Users,cn=permissions,cn=pbac,dc=ipa,dc=example
diff --git a/install/updates/60-trusts.update b/install/updates/60-trusts.update
index 371bf656fcdea6b7ec54aeb42c5afd25ef1b90f9..d55bc94bbe917571999bcc7dfb6e6aaf641c4b49 100644
--- a/install/updates/60-trusts.update
+++ b/install/updates/60-trusts.update
@@ -15,6 +15,14 @@ default: objectClass: GroupOfNames
default: objectClass: top
default: cn: adtrust agents
+dn: cn=ADTrust Agents,cn=privileges,cn=pbac,$SUFFIX
+default: objectClass: top
+default: objectClass: groupofnames
+default: objectClass: nestedgroup
+default: cn: ADTrust Agents
+default: description: System accounts able to access trust information
+default: member: cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX
+
dn: cn=trusts,$SUFFIX
default: objectClass: top
default: objectClass: nsContainer
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 25755d7a41e93b869f4d4afbf0ac094c42212451..565d87a77a923ac29763be5ffad8c8c67cd01588 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -330,6 +330,17 @@ class trust(LDAPObject):
'ipantsidblacklistincoming', 'ipantsidblacklistoutgoing'
},
},
+
+'System: Read system trust accounts': {
+'non_object': True,
+'ipapermlocation': DN(container_dn, api.env.basedn),
+'replaces_global_anonymous_aci': True,
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'uidnumber', 'gidnumber'
+},
+'default_privileges': {'ADTrust Agents'},
+},
}
label = _('Trusts')
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
On 24.6.2014 15:45, Tomas Mraz wrote: Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with AES according to RFC 3394 (no padding) or RFC 5649 (with padding). RFC 3394 works only on blocks of 64 bits, which is not our case because EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get proper padding etc. And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but OpenSSL doesn't support RFC 5649! The patch with this functionality was submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state new and there was no reply to the e-mail in the original thread [4]. I am sorry, but this does not make much sense to me. Iff the SoftHSM's C_WrapKey is really safe wrapping method for backing up and/or replicating HSM's it must provide wrapped key in such format that the IV is pregenerated as part of the Wrap operation and stored in the final blob of wrapped key. Unfortunately I do not know much of SoftHSM. SoftHSM is just PKCS#11 interface implementation so SoftHSM can't do something against PKCS#11 standard. In this case the standard says that user has to provide IV explicitly and the C_WrapKey should fall-back to standardized default if IV was not given by user. See section 6.13.3 AES Key Wrap in PKCS #11 Mechanisms v2.30: Cryptoki – Draft 7 on ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf What do we do? - Convince OpenSSL to review and accept the patch? I would say the patch is not too useful as is - there are multiple problems with it such as it is not using proper high level interfaces for the AES encryption, etc. Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different from the 2010-version. I didn't notice it. Would you review the patch if we re-write it against current OpenSSL git head? -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0267-0268] Preparation for 4.4 release
On 06/24/2014 05:37 PM, Petr Spacek wrote: On 23.6.2014 17:12, Petr Spacek wrote: Hello, Bump NVR to 4.4. Update NEWS for upcoming 4.4 release. Pushed to master: 2cd574e90a9fdebdbeaab45ef335e7d63e85dfd7 3a705963ed575f01b792a7e89d825cf56ce99734 At this point v4 branches from master. Just for my education - what is the branching model in bind-dyndb-ldap? In FreeIPA, we branch when we release FreeIPA x.y so that bugfixing releases FreeIPA x.y.z can be done. When you now branched at 4.4, do you plan to release bugfixes 4.4.x or rather 4.5, 4.6...? Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
On Tue, 2014-06-24 at 20:30 +0200, Petr Spacek wrote: On 24.6.2014 15:45, Tomas Mraz wrote: Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with AES according to RFC 3394 (no padding) or RFC 5649 (with padding). RFC 3394 works only on blocks of 64 bits, which is not our case because EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get proper padding etc. And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but OpenSSL doesn't support RFC 5649! The patch with this functionality was submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state new and there was no reply to the e-mail in the original thread [4]. I am sorry, but this does not make much sense to me. Iff the SoftHSM's C_WrapKey is really safe wrapping method for backing up and/or replicating HSM's it must provide wrapped key in such format that the IV is pregenerated as part of the Wrap operation and stored in the final blob of wrapped key. Unfortunately I do not know much of SoftHSM. SoftHSM is just PKCS#11 interface implementation so SoftHSM can't do something against PKCS#11 standard. In this case the standard says that user has to provide IV explicitly and the C_WrapKey should fall-back to standardized default if IV was not given by user. Sounds completely bogus, but in this case we'll have to either provide a random IV ourselves (and then store it alongside or provide data with a confounder at the start implementing padding on our own. See section 6.13.3 AES Key Wrap in PKCS #11 Mechanisms v2.30: Cryptoki – Draft 7 on ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf What do we do? - Convince OpenSSL to review and accept the patch? I would say the patch is not too useful as is - there are multiple problems with it such as it is not using proper high level interfaces for the AES encryption, etc. Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different from the 2010-version. I didn't notice it. Would you review the patch if we re-write it against current OpenSSL git head? -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
On Tue, 2014-06-24 at 15:33 -0400, Simo Sorce wrote: On Tue, 2014-06-24 at 20:30 +0200, Petr Spacek wrote: In this case the standard says that user has to provide IV explicitly and the C_WrapKey should fall-back to standardized default if IV was not given by user. Sounds completely bogus, but in this case we'll have to either provide a random IV ourselves (and then store it alongside or provide data with a Add the key data) here-^ Simo. confounder at the start implementing padding on our own. See section 6.13.3 AES Key Wrap in PKCS #11 Mechanisms v2.30: Cryptoki – Draft 7 on ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf What do we do? - Convince OpenSSL to review and accept the patch? I would say the patch is not too useful as is - there are multiple problems with it such as it is not using proper high level interfaces for the AES encryption, etc. Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different from the 2010-version. I didn't notice it. Would you review the patch if we re-write it against current OpenSSL git head? -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command
On 06/24/2014 06:44 PM, Alexander Bokovoy wrote:
On Tue, 24 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-24 at 19:34 +0300, Alexander Bokovoy wrote:
On Tue, 24 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote:
On Tue, 03 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote:
On 3.6.2014 05:08, Nathaniel McCallum wrote:
This command calls the token sync HTTP POST call in the server
providing
the CLI interface to synchronization.
https://fedorahosted.org/freeipa/ticket/4260
This patch depends on my patch #0055.
Build fails on validation. You forgot to update API.txt and also the
command misses __doc__.
(not a proper review)
Failed for me:
[root@ipa-01 rpms]# ipa otptoken-show test.token
Unique ID: test.token
Description: test token
Owner: abbra
Vendor: FreeIPA
Model: hotp
[root@ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token
Password:
First Code:
Second Code:
ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized',
httplib.HTTPMessage instance at 0x2cdde60)
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 129,
in execute
result = self.Command[_name](*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439,
in __call__
ret = self.run(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 1118,
in run
return self.forward(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py,
line 427, in forward
rsp = urllib.urlopen(sync_uri, query)
File /usr/lib64/python2.7/urllib.py, line 89, in urlopen
return opener.open(url, data)
File /usr/lib64/python2.7/urllib.py, line 210, in open
return getattr(self, name)(url, data)
File /usr/lib64/python2.7/urllib.py, line 454, in open_https
data)
File /usr/lib64/python2.7/urllib.py, line 374, in http_error
result = method(url, fp, errcode, errmsg, headers, data)
File /usr/lib64/python2.7/urllib.py, line 689, in http_error_401
errcode, errmsg, headers)
File /usr/lib64/python2.7/urllib.py, line 381, in http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 401, 'Unauthorized', httplib.HTTPMessage
instance at 0x2cdde60)
ipa: ERROR: an internal error has occurred
Note that I can successfully use the token. It looks like authentication
with urllib.urlopen(sync_uri, query) fails.
Works for me (just tested). I suspect you have not updated the ipa httpd
config. Did you apply patches 0054, 0055 and 0056?
Yes, I did apply those patches and I installed packages as an upgrade.
How I supposed to update httpd config? I think we need to solve this
without re-install and it should be done automatically.
Oh. I thought it *was* done automatically...
No. You only modified the template which is used for an install from
scratch.
It *will* get updated automatically if you bump the VERSION on the first line
of install/conf/ipa.conf.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command
On Tue, 2014-06-24 at 21:40 +0200, Martin Kosek wrote:
On 06/24/2014 06:44 PM, Alexander Bokovoy wrote:
On Tue, 24 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-24 at 19:34 +0300, Alexander Bokovoy wrote:
On Tue, 24 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote:
On Tue, 03 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote:
On 3.6.2014 05:08, Nathaniel McCallum wrote:
This command calls the token sync HTTP POST call in the server
providing
the CLI interface to synchronization.
https://fedorahosted.org/freeipa/ticket/4260
This patch depends on my patch #0055.
Build fails on validation. You forgot to update API.txt and also the
command misses __doc__.
(not a proper review)
Failed for me:
[root@ipa-01 rpms]# ipa otptoken-show test.token
Unique ID: test.token
Description: test token
Owner: abbra
Vendor: FreeIPA
Model: hotp
[root@ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token
Password:
First Code:
Second Code:
ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized',
httplib.HTTPMessage instance at 0x2cdde60)
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 129,
in execute
result = self.Command[_name](*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439,
in __call__
ret = self.run(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line
1118,
in run
return self.forward(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py,
line 427, in forward
rsp = urllib.urlopen(sync_uri, query)
File /usr/lib64/python2.7/urllib.py, line 89, in urlopen
return opener.open(url, data)
File /usr/lib64/python2.7/urllib.py, line 210, in open
return getattr(self, name)(url, data)
File /usr/lib64/python2.7/urllib.py, line 454, in open_https
data)
File /usr/lib64/python2.7/urllib.py, line 374, in http_error
result = method(url, fp, errcode, errmsg, headers, data)
File /usr/lib64/python2.7/urllib.py, line 689, in http_error_401
errcode, errmsg, headers)
File /usr/lib64/python2.7/urllib.py, line 381, in
http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 401, 'Unauthorized', httplib.HTTPMessage
instance at 0x2cdde60)
ipa: ERROR: an internal error has occurred
Note that I can successfully use the token. It looks like
authentication
with urllib.urlopen(sync_uri, query) fails.
Works for me (just tested). I suspect you have not updated the ipa httpd
config. Did you apply patches 0054, 0055 and 0056?
Yes, I did apply those patches and I installed packages as an upgrade.
How I supposed to update httpd config? I think we need to solve this
without re-install and it should be done automatically.
Oh. I thought it *was* done automatically...
No. You only modified the template which is used for an install from
scratch.
It *will* get updated automatically if you bump the VERSION on the first
line
of install/conf/ipa.conf.
Yup, I figured that out about 15 minutes ago by looking at your past
commits. :)
Nathaniel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0055] Add /session/token_sync POST support
On Mon, 2014-06-02 at 23:07 -0400, Nathaniel McCallum wrote: This HTTP call takes the following parameters: * user * password * first_code * second_code * token (optional) Using this information, the server will perform token synchronization. If the token is not specified, all tokens will be searched for synchronization. Otherwise, only the token specified will be searched. This patch depends on my patch #0054. Attached is a new revision. This version should force an update to /etc/httpd/conf.d/ipa.conf on update. It is also rebased on master. Nathaniel From 000eaaccaa3bff59138674f4144303107bda37af Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Wed, 28 May 2014 11:38:40 -0400 Subject: [PATCH] Add /session/token_sync POST support This HTTP call takes the following parameters: * user * password * first_code * second_code * token (optional) Using this information, the server will perform token synchronization. If the token is not specified, all tokens will be searched for synchronization. Otherwise, only the token specified will be searched. --- install/conf/ipa.conf | 8 +++- ipaserver/plugins/ldap2.py | 14 -- ipaserver/plugins/xmlserver.py | 3 +- ipaserver/rpcserver.py | 106 +++-- 4 files changed, 122 insertions(+), 9 deletions(-) diff --git a/install/conf/ipa.conf b/install/conf/ipa.conf index f4dac9827bd0251463aade5854fd522e4306e468..7eede73efc559967925d2bbfeee54e1e2efd3e21 100644 --- a/install/conf/ipa.conf +++ b/install/conf/ipa.conf @@ -1,5 +1,5 @@ # -# VERSION 15 - DO NOT REMOVE THIS LINE +# VERSION 16 - DO NOT REMOVE THIS LINE # # This file may be overwritten on upgrades. # @@ -103,6 +103,12 @@ KrbConstrainedDelegationLock ipa Allow from all /Location +Location /ipa/session/sync_token + Satisfy Any + Order Deny,Allow + Allow from all +/Location + # This is where we redirect on failed auth Alias /ipa/errors /usr/share/ipa/html diff --git a/ipaserver/plugins/ldap2.py b/ipaserver/plugins/ldap2.py index cfcec7c803215459cad2c08adae26a44099f2982..888f085b9f251bc933bc15c24a14b4107d4d4784 100644 --- a/ipaserver/plugins/ldap2.py +++ b/ipaserver/plugins/ldap2.py @@ -93,7 +93,7 @@ class ldap2(LDAPClient, CrudBackend): def create_connection(self, ccache=None, bind_dn=None, bind_pw='', tls_cacertfile=None, tls_certfile=None, tls_keyfile=None, -debug_level=0, autobind=False): +debug_level=0, autobind=False, serverctrls=None, clientctrls=None): Connect to LDAP server. @@ -151,16 +151,22 @@ class ldap2(LDAPClient, CrudBackend): context=krbV.default_context()).principal().name os.environ['KRB5CCNAME'] = ccache -conn.sasl_interactive_bind_s(None, SASL_GSSAPI) +conn.sasl_interactive_bind_s(None, SASL_GSSAPI, + serverctrls=serverctrls, + clientctrls=clientctrls) setattr(context, 'principal', principal) else: # no kerberos ccache, use simple bind or external sasl if autobind: pent = pwd.getpwuid(os.geteuid()) auth_tokens = _ldap.sasl.external(pent.pw_name) -conn.sasl_interactive_bind_s(None, auth_tokens) +conn.sasl_interactive_bind_s(None, auth_tokens, + serverctrls=serverctrls, + clientctrls=clientctrls) else: -conn.simple_bind_s(bind_dn, bind_pw) +conn.simple_bind_s(bind_dn, bind_pw, + serverctrls=serverctrls, + clientctrls=clientctrls) return conn diff --git a/ipaserver/plugins/xmlserver.py b/ipaserver/plugins/xmlserver.py index 8d96262cf52f04620aeb5223002f4794e18cc0de..7460ead69a12fbe1b4613908f62787f3d26a1cde 100644 --- a/ipaserver/plugins/xmlserver.py +++ b/ipaserver/plugins/xmlserver.py @@ -25,7 +25,7 @@ Loads WSGI server plugins. from ipalib import api if 'in_server' in api.env and api.env.in_server is True: -from ipaserver.rpcserver import wsgi_dispatch, xmlserver, jsonserver_kerb, jsonserver_session, login_kerberos, login_password, change_password, xmlserver_session +from ipaserver.rpcserver import wsgi_dispatch, xmlserver, jsonserver_kerb, jsonserver_session, login_kerberos, login_password, change_password, sync_token, xmlserver_session api.register(wsgi_dispatch) api.register(xmlserver) api.register(jsonserver_kerb) @@ -33,4 +33,5 @@ if 'in_server' in api.env and api.env.in_server is True: api.register(login_kerberos) api.register(login_password) api.register(change_password) +api.register(sync_token)
Re: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command
On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote:
On Tue, 03 Jun 2014, Nathaniel McCallum wrote:
On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote:
On 3.6.2014 05:08, Nathaniel McCallum wrote:
This command calls the token sync HTTP POST call in the server providing
the CLI interface to synchronization.
https://fedorahosted.org/freeipa/ticket/4260
This patch depends on my patch #0055.
Build fails on validation. You forgot to update API.txt and also the
command misses __doc__.
(not a proper review)
Failed for me:
[root@ipa-01 rpms]# ipa otptoken-show test.token
Unique ID: test.token
Description: test token
Owner: abbra
Vendor: FreeIPA
Model: hotp
[root@ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token
Password:
First Code:
Second Code:
ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized',
httplib.HTTPMessage instance at 0x2cdde60)
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 129,
in execute
result = self.Command[_name](*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439,
in __call__
ret = self.run(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 1118,
in run
return self.forward(*args, **options)
File /usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py,
line 427, in forward
rsp = urllib.urlopen(sync_uri, query)
File /usr/lib64/python2.7/urllib.py, line 89, in urlopen
return opener.open(url, data)
File /usr/lib64/python2.7/urllib.py, line 210, in open
return getattr(self, name)(url, data)
File /usr/lib64/python2.7/urllib.py, line 454, in open_https
data)
File /usr/lib64/python2.7/urllib.py, line 374, in http_error
result = method(url, fp, errcode, errmsg, headers, data)
File /usr/lib64/python2.7/urllib.py, line 689, in http_error_401
errcode, errmsg, headers)
File /usr/lib64/python2.7/urllib.py, line 381, in http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 401, 'Unauthorized', httplib.HTTPMessage instance at
0x2cdde60)
ipa: ERROR: an internal error has occurred
Note that I can successfully use the token. It looks like authentication
with urllib.urlopen(sync_uri, query) fails.
This should be fixed in 0055.1.
Nathaniel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0267-0268] Preparation for 4.4 release
On (24/06/14 21:34), Martin Kosek wrote: On 06/24/2014 05:37 PM, Petr Spacek wrote: On 23.6.2014 17:12, Petr Spacek wrote: Hello, Bump NVR to 4.4. Update NEWS for upcoming 4.4 release. Pushed to master: 2cd574e90a9fdebdbeaab45ef335e7d63e85dfd7 3a705963ed575f01b792a7e89d825cf56ce99734 At this point v4 branches from master. Just for my education - what is the branching model in bind-dyndb-ldap? In FreeIPA, we branch when we release FreeIPA x.y so that bugfixing releases FreeIPA x.y.z can be done. When you now branched at 4.4, do you plan to release bugfixes 4.4.x or rather 4.5, 4.6...? Numbers are cheap. bind-dyndb-ldap is small project. It will be simpler to use only two numbers for version. LS ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command
On Tue, 2014-06-03 at 09:18 -0400, Nathaniel McCallum wrote:
On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote:
On 3.6.2014 05:08, Nathaniel McCallum wrote:
This command calls the token sync HTTP POST call in the server providing
the CLI interface to synchronization.
https://fedorahosted.org/freeipa/ticket/4260
This patch depends on my patch #0055.
Build fails on validation. You forgot to update API.txt and also the
command misses __doc__.
(not a proper review)
Thanks, fixed.
Attached is a new revision which is rebased on master.
In addition it:
1. Moves user to a parameter and moves token to an argument. Doing it
this way both mirrors the existing otptoken APIs and sets us up for
future Kerberos based syncing where the username/password will be
optional.
2. Converts the token ID to a DN.
Nathaniel
From 6876cabce395ab3aee87ce2f9de3a0cb353fae47 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Mon, 2 Jun 2014 23:00:52 -0400
Subject: [PATCH] Add otptoken-sync command
This command calls the token sync HTTP POST call in the server providing
the CLI interface to synchronization.
https://fedorahosted.org/freeipa/ticket/4260
---
API.txt| 9
ipalib/plugins/otptoken.py | 56 +-
2 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/API.txt b/API.txt
index 0dd28068edbd37f021a58195941e102c25fa360f..ab09b089d1ff525de82c2044fac939b78a2afa05 100644
--- a/API.txt
+++ b/API.txt
@@ -2408,6 +2408,15 @@ option: Str('version?', exclude='webui')
output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: PrimaryKey('value', None, None)
+command: otptoken_sync
+args: 1,5,1
+arg: Str('token?')
+option: Password('first_code', confirm=False)
+option: Password('password', confirm=False)
+option: Password('second_code', confirm=False)
+option: Str('user')
+option: Str('version?', exclude='webui')
+output: Output('result', None, None)
command: passwd
args: 3,1,3
arg: Str('principal', autofill=True, cli_name='user', primary_key=True)
diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py
index d834d582a16d95ab08c3f1fe1aef29160c77ae23..035328ce3260dd1c784a7cdb2aa4bf54fe6e7a27 100644
--- a/ipalib/plugins/otptoken.py
+++ b/ipalib/plugins/otptoken.py
@@ -19,13 +19,16 @@
from ipalib.plugins.baseldap import DN, LDAPObject, LDAPAddMember, LDAPRemoveMember
from ipalib.plugins.baseldap import LDAPCreate, LDAPDelete, LDAPUpdate, LDAPSearch, LDAPRetrieve
-from ipalib import api, Int, Str, Bool, Flag, Bytes, IntEnum, StrEnum, _, ngettext
+from ipalib import api, Int, Str, Bool, Flag, Bytes, IntEnum, StrEnum, Password, _, ngettext
from ipalib.plugable import Registry
from ipalib.errors import PasswordMismatch, ConversionError, LastMemberError, NotFound
from ipalib.request import context
+from ipalib.frontend import Local
+
import base64
import uuid
import urllib
+import urlparse
import qrcode
import os
@@ -383,3 +386,54 @@ class otptoken_remove_managedby(LDAPRemoveMember):
__doc__ = _('Remove hosts that can manage this host.')
member_attributes = ['managedby']
+
+@register()
+class otptoken_sync(Local):
+__doc__ = _('Synchronize an OTP token.')
+
+header = 'X-IPA-TokenSync-Result'
+
+takes_options = (
+Str('user', label=_('User ID')),
+Password('password', label=_('Password'), confirm=False),
+Password('first_code', label=_('First Code'), confirm=False),
+Password('second_code', label=_('Second Code'), confirm=False),
+)
+
+takes_args = (
+Str('token?', label=_('Token ID')),
+)
+
+def forward(self, *args, **kwargs):
+status = {'result': {self.header: 'unknown'}}
+
+# Get the sync URI.
+segments = list(urlparse.urlparse(self.api.env.xmlrpc_uri))
+assert segments[0] == 'https' # Ensure encryption.
+segments[2] = segments[2].replace('/xml', '/session/sync_token')
+sync_uri = urlparse.urlunparse(segments)
+
+# Prepare the query.
+query = {k: v for k, v in kwargs.items()
+if k in {x.name for x in self.takes_options}}
+if args and args[0] is not None:
+obj = self.api.Object.otptoken
+query['token'] = DN((obj.primary_key.name, args[0]),
+obj.container_dn, self.api.env.basedn)
+query = urllib.urlencode(query)
+
+# Sync the token.
+# WARNING: This does not validate the server's certificate.
+rsp = urllib.urlopen(sync_uri, query)
+if rsp.getcode() == 200:
+status['result'][self.header] = rsp.info().get(self.header, 'unknown')
+rsp.close()
+
+return status
+
+def output_for_cli(self, textui, result, *keys, **options):
+
