Re: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew
On 12/09/2014 01:56 PM, Jan Cholasta wrote: Dne 5.12.2014 v 12:01 Jan Cholasta napsal(a): Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): On 12/05/2014 11:34 AM, Jan Cholasta wrote: Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): On 12/04/2014 09:36 AM, Jan Cholasta wrote: +if x509.get_der_subject(cert, x509.DER) != der_subject: +raise admintool.ScriptError(Subject name encoding mismatch) I think we can expect this to be a pretty common error, given this is the default behavior of Microsoft Certificate Services. I would thus like to make the error message more juicy. We need to make sure we offer some pointers for these users or they will just blame IPA for screwing up. So, the information I wrote https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 need to somehow get to the error message as a potential/likely root cause of the problem. Whether you write it in the error message itself or update the design page and just insert a link is up to you. Martin I would rather document this and have users read the documentation, which they should do anyway when something goes wrong. There are many errors in IPA which are common and users may blame IPA for them and I don't see what makes this one so special that it should require a special treatment. I saw several reasons: - Certificateinstallation error are more common than the others and users are usually quite lost in what to do with them. - In this case, we know by 90% probability what is the root cause - It will block one of the main use cases for the new CA renewal tool and people will likely hit it as MS CAs is one of the most common CAs and this is it's default behavior. Giving more details in this case will not hurt us, but benefit users. So I still do not see the harm. I do not see a harm either, my point is that we should probably point the user to documentation when *anything* in *any* script goes wrong, not just when some arbitrarily cherry-picked error occurs. Anyway, I have created http://www.freeipa.org/page/Troubleshooting#External_CA_renewal_with_ipa-cacert-manage_fails. Good. Do you plan to reference the section or enhance the error message? I plan to reference http://www.freeipa.org/page/Troubleshooting. See the attached patch (385). I think the reference for the Troubleshooting page should be more narrow so that people only see the URL only for the cases we give specific advise for. Otherwise I assume they will just ignore the page if they do not find the advise for other errors. Other idea would be to give reference to the article when the actual CSR is generated - as a heads up. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 9.12.2014 13:40, Martin Kosek wrote: On 12/03/2014 05:04 PM, Petr Spacek wrote: On 2.12.2014 17:21, Simo Sorce wrote: On Tue, 02 Dec 2014 15:56:28 +0100 Petr Spacek pspa...@redhat.com wrote: On 1.12.2014 17:12, Simo Sorce wrote: On Mon, 01 Dec 2014 16:17:54 +0100 Petr Spacek pspa...@redhat.com wrote: On 14.11.2014 17:31, Petr Spacek wrote: On 14.11.2014 02:22, Simo Sorce wrote: On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek pspa...@redhat.com wrote: Hello, this thread is about RFE IPA servers when installed should register themselves in the external DNS https://fedorahosted.org/freeipa/ticket/4424 It is not a complete design, just a raw idea. Use case FreeIPA installation to a network with existing DNS infrastructure + network administrator who is not willing to add/maintain new DNS servers just for FreeIPA. High-level idea === - Transform dns* commands from FreeIPA framework to equivalent nsupdate commands and send DNS updates to existing DNS servers. - Provide necessary encryption/signing keys to nsupdate. 1) Integration to FreeIPA framework === First of all, we need to decide if external DNS integration can be used at the same time with FreeIPA-integrated DNS or not. Side-question is what to do if a first server is installed with external-DNS but another replica is being installed with integrated-DNS and so on. I think being able to integrate with an external DNS is important, and not just at the server level, being able to distribute TSIG keys to client would be nice too, though a lot less important, than getting server integration.. Using TSIG on many clients is very problematic. Keep in mind that TSIG is basically HMAC computed using symmetric key so: a) Every client would have to use the same key - this is a security nightmare. b) We would have to distribute and maintain many keys for many^2 clients, which is an administrative nightmare. For *clients* I would rather stay with GSS-TSIG which is much more manageable because we can use Kerberos trust and Keytab distribution is already solved by ipa-client-install. Alternative for clients would be to use FreeIPA server as proxy which encapsulates TSIG keys and issues update requests on behalf of clients. This would be FreeIPA-specific but any TSIG-distribution mechanism will be FreeIPA-specific anyway. TSIG standard explicitly says that there is no standardized distribution mechanism. In other words, the question is if current dns.py plugin shipped with FreeIPA framework should be: a) Extended dns.py with dnsexternal-* commands -- Disadvantages: - It complicate FreeIPA DNS interface which is a complex beast even now. - We would have add condition to every DNS API call in installers which would increase horribleness of the installer code even more (or add another layer of abstraction...). I agree having a special command is undesirable. - I don't see a point in using integrated-DNS with external-DNS at the same time. To use integrated-DNS you have to get a proper DNS delegation from parent domain - and if you can get the delegation then there is no point in using external DNS ... I disagree on this point, it makes a lot of sense to have some zones maintained by IPA and ... some not. Advantages: - You can use external integrated DNS at the same time. We can achieve the same w/o a new ipa level command. This needs to be decided by FreeIPA framework experts ... Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would provide all ipa dns* commands and dispatch user-issued commands to appropriate FreeIPA-plugin (internal-dns or external-dns). This decision could depend on some values in LDAP. b) Replace dns.py with another implementation of current dnszone-* dnsrecord-* API. - This seems like a cleaner approach to me. It could be shipped as ipa-server-dns-external package (opposed to standard ipa-server-dns package). Advantages: - It could seamlessly work with FreeIPA client installer because the dns*-nsupdate command transformation would be done on FreeIPA server and client doesn't need to know about it. - Does not require re-training/not much new documentation because commands are the same. Disadvantages: - You can't use integrated external DNS at the same time (but I don't think it justifies the added complexity). I disagree. One of the reason to use a mix is to allow smooth migrations where zones are moved into (or out of) IPA one by one. Good point, I agree. I will focus on supporting both (internal and external) DNS at the same time. Petr^3 or anyone else, what do you propose? I think what I'd like to see is to be able to configure a DNS zone in LDAP and mark it external. The zone would held the TSIG keys necessary to perform DNS
[Freeipa-devel] [PATCH 0040] Remove dependency on subscription-manager
Hello,
Fix for https://fedorahosted.org/freeipa/ticket/4783
Thanks,
Gabe
From 11c688db6f741e9747716de023dcc86728e090eb Mon Sep 17 00:00:00 2001
From: Gabe redhatri...@gmail.com
Date: Wed, 10 Dec 2014 07:18:35 -0700
Subject: [PATCH] Remove dependency on subscription-manager
https://fedorahosted.org/freeipa/ticket/4783
---
freeipa.spec.in |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 9b12c20899e729cedacdee470f8f2b13250af4e0..11af2d6626cfcba60ef3e4a63edc262e6d1ca10b 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -133,9 +133,6 @@ Requires(post): selinux-policy-base
Requires: slapi-nis = 0.54.1-1
Requires: pki-ca = 10.2.1-0.1
Requires: pki-kra = 10.2.1-0.1
-%if 0%{?rhel}
-Requires: subscription-manager
-%endif
Requires(preun): python systemd-units
Requires(postun): python systemd-units
Requires: python-dns = 1.11.1
--
1.7.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 12/10/2014 03:13 PM, Petr Spacek wrote: On 9.12.2014 13:40, Martin Kosek wrote: On 12/03/2014 05:04 PM, Petr Spacek wrote: On 2.12.2014 17:21, Simo Sorce wrote: On Tue, 02 Dec 2014 15:56:28 +0100 Petr Spacek pspa...@redhat.com wrote: On 1.12.2014 17:12, Simo Sorce wrote: On Mon, 01 Dec 2014 16:17:54 +0100 Petr Spacek pspa...@redhat.com wrote: On 14.11.2014 17:31, Petr Spacek wrote: On 14.11.2014 02:22, Simo Sorce wrote: On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek pspa...@redhat.com wrote: Hello, this thread is about RFE IPA servers when installed should register themselves in the external DNS https://fedorahosted.org/freeipa/ticket/4424 It is not a complete design, just a raw idea. Use case FreeIPA installation to a network with existing DNS infrastructure + network administrator who is not willing to add/maintain new DNS servers just for FreeIPA. High-level idea === - Transform dns* commands from FreeIPA framework to equivalent nsupdate commands and send DNS updates to existing DNS servers. - Provide necessary encryption/signing keys to nsupdate. 1) Integration to FreeIPA framework === First of all, we need to decide if external DNS integration can be used at the same time with FreeIPA-integrated DNS or not. Side-question is what to do if a first server is installed with external-DNS but another replica is being installed with integrated-DNS and so on. I think being able to integrate with an external DNS is important, and not just at the server level, being able to distribute TSIG keys to client would be nice too, though a lot less important, than getting server integration.. Using TSIG on many clients is very problematic. Keep in mind that TSIG is basically HMAC computed using symmetric key so: a) Every client would have to use the same key - this is a security nightmare. b) We would have to distribute and maintain many keys for many^2 clients, which is an administrative nightmare. For *clients* I would rather stay with GSS-TSIG which is much more manageable because we can use Kerberos trust and Keytab distribution is already solved by ipa-client-install. Alternative for clients would be to use FreeIPA server as proxy which encapsulates TSIG keys and issues update requests on behalf of clients. This would be FreeIPA-specific but any TSIG-distribution mechanism will be FreeIPA-specific anyway. TSIG standard explicitly says that there is no standardized distribution mechanism. In other words, the question is if current dns.py plugin shipped with FreeIPA framework should be: a) Extended dns.py with dnsexternal-* commands -- Disadvantages: - It complicate FreeIPA DNS interface which is a complex beast even now. - We would have add condition to every DNS API call in installers which would increase horribleness of the installer code even more (or add another layer of abstraction...). I agree having a special command is undesirable. - I don't see a point in using integrated-DNS with external-DNS at the same time. To use integrated-DNS you have to get a proper DNS delegation from parent domain - and if you can get the delegation then there is no point in using external DNS ... I disagree on this point, it makes a lot of sense to have some zones maintained by IPA and ... some not. Advantages: - You can use external integrated DNS at the same time. We can achieve the same w/o a new ipa level command. This needs to be decided by FreeIPA framework experts ... Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would provide all ipa dns* commands and dispatch user-issued commands to appropriate FreeIPA-plugin (internal-dns or external-dns). This decision could depend on some values in LDAP. b) Replace dns.py with another implementation of current dnszone-* dnsrecord-* API. - This seems like a cleaner approach to me. It could be shipped as ipa-server-dns-external package (opposed to standard ipa-server-dns package). Advantages: - It could seamlessly work with FreeIPA client installer because the dns*-nsupdate command transformation would be done on FreeIPA server and client doesn't need to know about it. - Does not require re-training/not much new documentation because commands are the same. Disadvantages: - You can't use integrated external DNS at the same time (but I don't think it justifies the added complexity). I disagree. One of the reason to use a mix is to allow smooth migrations where zones are moved into (or out of) IPA one by one. Good point, I agree. I will focus on supporting both (internal and external) DNS at the same time. Petr^3 or anyone else, what do you propose? I think what I'd like to see is to be able to configure a DNS zone in LDAP and mark it external. The zone would held
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 10.12.2014 15:50, Martin Kosek wrote: On 12/10/2014 03:13 PM, Petr Spacek wrote: On 9.12.2014 13:40, Martin Kosek wrote: On 12/03/2014 05:04 PM, Petr Spacek wrote: On 2.12.2014 17:21, Simo Sorce wrote: On Tue, 02 Dec 2014 15:56:28 +0100 Petr Spacek pspa...@redhat.com wrote: On 1.12.2014 17:12, Simo Sorce wrote: On Mon, 01 Dec 2014 16:17:54 +0100 Petr Spacek pspa...@redhat.com wrote: On 14.11.2014 17:31, Petr Spacek wrote: On 14.11.2014 02:22, Simo Sorce wrote: On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek pspa...@redhat.com wrote: Hello, this thread is about RFE IPA servers when installed should register themselves in the external DNS https://fedorahosted.org/freeipa/ticket/4424 It is not a complete design, just a raw idea. Use case FreeIPA installation to a network with existing DNS infrastructure + network administrator who is not willing to add/maintain new DNS servers just for FreeIPA. High-level idea === - Transform dns* commands from FreeIPA framework to equivalent nsupdate commands and send DNS updates to existing DNS servers. - Provide necessary encryption/signing keys to nsupdate. 1) Integration to FreeIPA framework === First of all, we need to decide if external DNS integration can be used at the same time with FreeIPA-integrated DNS or not. Side-question is what to do if a first server is installed with external-DNS but another replica is being installed with integrated-DNS and so on. I think being able to integrate with an external DNS is important, and not just at the server level, being able to distribute TSIG keys to client would be nice too, though a lot less important, than getting server integration.. Using TSIG on many clients is very problematic. Keep in mind that TSIG is basically HMAC computed using symmetric key so: a) Every client would have to use the same key - this is a security nightmare. b) We would have to distribute and maintain many keys for many^2 clients, which is an administrative nightmare. For *clients* I would rather stay with GSS-TSIG which is much more manageable because we can use Kerberos trust and Keytab distribution is already solved by ipa-client-install. Alternative for clients would be to use FreeIPA server as proxy which encapsulates TSIG keys and issues update requests on behalf of clients. This would be FreeIPA-specific but any TSIG-distribution mechanism will be FreeIPA-specific anyway. TSIG standard explicitly says that there is no standardized distribution mechanism. In other words, the question is if current dns.py plugin shipped with FreeIPA framework should be: a) Extended dns.py with dnsexternal-* commands -- Disadvantages: - It complicate FreeIPA DNS interface which is a complex beast even now. - We would have add condition to every DNS API call in installers which would increase horribleness of the installer code even more (or add another layer of abstraction...). I agree having a special command is undesirable. - I don't see a point in using integrated-DNS with external-DNS at the same time. To use integrated-DNS you have to get a proper DNS delegation from parent domain - and if you can get the delegation then there is no point in using external DNS ... I disagree on this point, it makes a lot of sense to have some zones maintained by IPA and ... some not. Advantages: - You can use external integrated DNS at the same time. We can achieve the same w/o a new ipa level command. This needs to be decided by FreeIPA framework experts ... Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would provide all ipa dns* commands and dispatch user-issued commands to appropriate FreeIPA-plugin (internal-dns or external-dns). This decision could depend on some values in LDAP. b) Replace dns.py with another implementation of current dnszone-* dnsrecord-* API. - This seems like a cleaner approach to me. It could be shipped as ipa-server-dns-external package (opposed to standard ipa-server-dns package). Advantages: - It could seamlessly work with FreeIPA client installer because the dns*-nsupdate command transformation would be done on FreeIPA server and client doesn't need to know about it. - Does not require re-training/not much new documentation because commands are the same. Disadvantages: - You can't use integrated external DNS at the same time (but I don't think it justifies the added complexity). I disagree. One of the reason to use a mix is to allow smooth migrations where zones are moved into (or out of) IPA one by one. Good point, I agree. I will focus on supporting both (internal and external) DNS at the same time. Petr^3 or anyone else, what do you propose? I think what I'd like to see is to be able to configure a DNS zone in LDAP
Re: [Freeipa-devel] [PATCH 0040] Remove dependency on subscription-manager
On 10/12/14 15:45, Gabe Alford wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4783 Thanks, Gabe Hello, thanks for patch. The patch needs rebase for IPA-4-1 branch Martin^2 -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew
On 12/10/2014 02:35 PM, Jan Cholasta wrote: Dne 10.12.2014 v 11:53 Martin Kosek napsal(a): On 12/09/2014 01:56 PM, Jan Cholasta wrote: Dne 5.12.2014 v 12:01 Jan Cholasta napsal(a): Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): On 12/05/2014 11:34 AM, Jan Cholasta wrote: Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): On 12/04/2014 09:36 AM, Jan Cholasta wrote: +if x509.get_der_subject(cert, x509.DER) != der_subject: +raise admintool.ScriptError(Subject name encoding mismatch) I think we can expect this to be a pretty common error, given this is the default behavior of Microsoft Certificate Services. I would thus like to make the error message more juicy. We need to make sure we offer some pointers for these users or they will just blame IPA for screwing up. So, the information I wrote https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 need to somehow get to the error message as a potential/likely root cause of the problem. Whether you write it in the error message itself or update the design page and just insert a link is up to you. Martin I would rather document this and have users read the documentation, which they should do anyway when something goes wrong. There are many errors in IPA which are common and users may blame IPA for them and I don't see what makes this one so special that it should require a special treatment. I saw several reasons: - Certificateinstallation error are more common than the others and users are usually quite lost in what to do with them. - In this case, we know by 90% probability what is the root cause - It will block one of the main use cases for the new CA renewal tool and people will likely hit it as MS CAs is one of the most common CAs and this is it's default behavior. Giving more details in this case will not hurt us, but benefit users. So I still do not see the harm. I do not see a harm either, my point is that we should probably point the user to documentation when *anything* in *any* script goes wrong, not just when some arbitrarily cherry-picked error occurs. Anyway, I have created http://www.freeipa.org/page/Troubleshooting#External_CA_renewal_with_ipa-cacert-manage_fails. Good. Do you plan to reference the section or enhance the error message? I plan to reference http://www.freeipa.org/page/Troubleshooting. See the attached patch (385). I think the reference for the Troubleshooting page should be more narrow so that people only see the URL only for the cases we give specific advise for. Otherwise I assume they will just ignore the page if they do not find the advise for other errors. Right, makes sense. Other idea would be to give reference to the article when the actual CSR is generated - as a heads up. I think referring to troubleshooting before there actually is some trouble is not very good for publicity. Ah, that's a good point - in this purpose it would be better to have it somewhere else or only refer to the MS article. Anyway, updated patch attached, it implements what you suggested originally - link to the troubleshooting guide is added to relevant error messages. Let's think about this in more broad terms when the time comes for the installer refactoring. Ok. I am fine with the patch conceptually. So now just someone (David?) needs to make sure it did not break anything :-) Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew
On 10/12/14 16:02, Martin Kosek wrote: On 12/10/2014 02:35 PM, Jan Cholasta wrote: Dne 10.12.2014 v 11:53 Martin Kosek napsal(a): On 12/09/2014 01:56 PM, Jan Cholasta wrote: Dne 5.12.2014 v 12:01 Jan Cholasta napsal(a): Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): On 12/05/2014 11:34 AM, Jan Cholasta wrote: Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): On 12/04/2014 09:36 AM, Jan Cholasta wrote: +if x509.get_der_subject(cert, x509.DER) != der_subject: +raise admintool.ScriptError(Subject name encoding mismatch) I think we can expect this to be a pretty common error, given this is the default behavior of Microsoft Certificate Services. I would thus like to make the error message more juicy. We need to make sure we offer some pointers for these users or they will just blame IPA for screwing up. So, the information I wrote https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 need to somehow get to the error message as a potential/likely root cause of the problem. Whether you write it in the error message itself or update the design page and just insert a link is up to you. Martin I would rather document this and have users read the documentation, which they should do anyway when something goes wrong. There are many errors in IPA which are common and users may blame IPA for them and I don't see what makes this one so special that it should require a special treatment. I saw several reasons: - Certificateinstallation error are more common than the others and users are usually quite lost in what to do with them. - In this case, we know by 90% probability what is the root cause - It will block one of the main use cases for the new CA renewal tool and people will likely hit it as MS CAs is one of the most common CAs and this is it's default behavior. Giving more details in this case will not hurt us, but benefit users. So I still do not see the harm. I do not see a harm either, my point is that we should probably point the user to documentation when *anything* in *any* script goes wrong, not just when some arbitrarily cherry-picked error occurs. Anyway, I have created http://www.freeipa.org/page/Troubleshooting#External_CA_renewal_with_ipa-cacert-manage_fails. Good. Do you plan to reference the section or enhance the error message? I plan to reference http://www.freeipa.org/page/Troubleshooting. See the attached patch (385). I think the reference for the Troubleshooting page should be more narrow so that people only see the URL only for the cases we give specific advise for. Otherwise I assume they will just ignore the page if they do not find the advise for other errors. Right, makes sense. Other idea would be to give reference to the article when the actual CSR is generated - as a heads up. I think referring to troubleshooting before there actually is some trouble is not very good for publicity. Ah, that's a good point - in this purpose it would be better to have it somewhere else or only refer to the MS article. Anyway, updated patch attached, it implements what you suggested originally - link to the troubleshooting guide is added to relevant error messages. Let's think about this in more broad terms when the time comes for the installer refactoring. Ok. I am fine with the patch conceptually. So now just someone (David?) needs to make sure it did not break anything :-) Martin ACK, seems it doesnt break anything. -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0168] Better workaround to get status of CA during upgrade
Dne 1.12.2014 v 16:48 Martin Basti napsal(a): On 01/12/14 08:46, Jan Cholasta wrote: Hi, Dne 27.11.2014 v 14:24 Martin Basti napsal(a): Ticket: https://fedorahosted.org/freeipa/ticket/4676 Replaces current workaround. Should go to 4.1.3. Patch attached. When constructing URLs with host:port, please use ipautil.format_netloc(). wget should be added as a dependency of freeipa-python in the spec file. Honza Updated patch attached. Thanks, ACK. Pushed to: master: 337faf506462a01c6dbcd00f2039ed5627691864 ipa-4-1: 5052af773f652bc19e91fe49e15351e5c5c7d976 -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew
Dne 9.12.2014 v 13:03 David Kupka napsal(a): On 12/04/2014 09:36 AM, Jan Cholasta wrote: Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4781. Honza ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Works for me, ACK. Thanks for the review. Pushed to: master: f7f3c83748b3b5d5d968cc3c72145f3c5f23cd8b ipa-4-1: 731035e526441b93b69fb20c6a6c990cdcdc4899 -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew
Dne 10.12.2014 v 17:53 Martin Basti napsal(a): On 10/12/14 16:02, Martin Kosek wrote: On 12/10/2014 02:35 PM, Jan Cholasta wrote: Dne 10.12.2014 v 11:53 Martin Kosek napsal(a): On 12/09/2014 01:56 PM, Jan Cholasta wrote: Dne 5.12.2014 v 12:01 Jan Cholasta napsal(a): Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): On 12/05/2014 11:34 AM, Jan Cholasta wrote: Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): On 12/04/2014 09:36 AM, Jan Cholasta wrote: +if x509.get_der_subject(cert, x509.DER) != der_subject: +raise admintool.ScriptError(Subject name encoding mismatch) I think we can expect this to be a pretty common error, given this is the default behavior of Microsoft Certificate Services. I would thus like to make the error message more juicy. We need to make sure we offer some pointers for these users or they will just blame IPA for screwing up. So, the information I wrote https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 need to somehow get to the error message as a potential/likely root cause of the problem. Whether you write it in the error message itself or update the design page and just insert a link is up to you. Martin I would rather document this and have users read the documentation, which they should do anyway when something goes wrong. There are many errors in IPA which are common and users may blame IPA for them and I don't see what makes this one so special that it should require a special treatment. I saw several reasons: - Certificateinstallation error are more common than the others and users are usually quite lost in what to do with them. - In this case, we know by 90% probability what is the root cause - It will block one of the main use cases for the new CA renewal tool and people will likely hit it as MS CAs is one of the most common CAs and this is it's default behavior. Giving more details in this case will not hurt us, but benefit users. So I still do not see the harm. I do not see a harm either, my point is that we should probably point the user to documentation when *anything* in *any* script goes wrong, not just when some arbitrarily cherry-picked error occurs. Anyway, I have created http://www.freeipa.org/page/Troubleshooting#External_CA_renewal_with_ipa-cacert-manage_fails. Good. Do you plan to reference the section or enhance the error message? I plan to reference http://www.freeipa.org/page/Troubleshooting. See the attached patch (385). I think the reference for the Troubleshooting page should be more narrow so that people only see the URL only for the cases we give specific advise for. Otherwise I assume they will just ignore the page if they do not find the advise for other errors. Right, makes sense. Other idea would be to give reference to the article when the actual CSR is generated - as a heads up. I think referring to troubleshooting before there actually is some trouble is not very good for publicity. Ah, that's a good point - in this purpose it would be better to have it somewhere else or only refer to the MS article. Anyway, updated patch attached, it implements what you suggested originally - link to the troubleshooting guide is added to relevant error messages. Let's think about this in more broad terms when the time comes for the installer refactoring. Ok. I am fine with the patch conceptually. So now just someone (David?) needs to make sure it did not break anything :-) Martin ACK, seems it doesnt break anything. Thanks for the review. Pushed to: master: 8f9c5988e2f370cef66a4cd7cf3d363f061a439c ipa-4-1: 3cb2f5e841f5bac6a8cc02bc9467846b35f7aab8 -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration
On 09/12/14 17:40, Martin Basti wrote: On 01/12/14 17:44, Petr Spacek wrote: On 1.12.2014 14:39, Martin Basti wrote: On 24/11/14 17:24, Petr Spacek wrote: Hello! Thank you for the patch. It is not ready yet but the overall direction seems good. Please see my comments in-line. On 24.11.2014 14:35, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4721 Patch attached -- Martin Basti freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Fri, 21 Nov 2014 16:54:09 +0100 Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration Shows warning if forward and parent authoritative zone do not have proper NS record delegation, which can cause the forward zone will be ineffective and forwarding will not work. The chande in the test was required due python changes order of elemnts in dict (python doesnt guarantee an order in dict) Ticket: https://fedorahosted.org/freeipa/ticket/4721 --- ipalib/messages.py | 12 +++ ipalib/plugins/dns.py | 147 +--- ipatests/test_xmlrpc/test_dns_plugin.py | 2 +- 3 files changed, 149 insertions(+), 12 deletions(-) diff --git a/ipalib/messages.py b/ipalib/messages.py index 102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f 100644 --- a/ipalib/messages.py +++ b/ipalib/messages.py @@ -200,6 +200,18 @@ class DNSServerDoesNotSupportDNSSECWarning(PublicMessage): uIf DNSSEC validation is enabled on IPA server(s), uplease disable it.) +class ForwardzoneIsNotEffectiveWarning(PublicMessage): + +**13008** Forwardzone is not effective, forwarding will not work because +there is authoritative parent zone, without proper NS delegation + + +errno = 13008 +type = warning +format = _(uforward zone \%(fwzone)s\ is not effective (missing proper + uNS delegation in authoritative zone \%(authzone)s\). + uForwarding may not work.) I think that the error message could be made mode useful: Forwarding will not work. Please add NS record fwdzone.relativize(authzone) to parent zone %(authzone)s (or something like that). + def iter_messages(variables, base): Return a tuple with all subclasses diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py index c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229 100644 --- a/ipalib/plugins/dns.py +++ b/ipalib/plugins/dns.py @@ -1725,6 +1725,79 @@ def _normalize_zone(zone): return zone +def _find_zone_which_makes_fw_zone_ineffective(fwzonename): Generally, this method finds an authoritative zone for given fwzonename. What about method name _find_auth_zone_ldap(name) ? + +Check if forward zone is effective. + +If parent zone exists as authoritative zone, forward zone will not +forward queries. It is necessary to delegate authority of forward zone I would clarify it: forward queries by default. +to another server (non IPA DNS server). I would personally omit (non IPA DNS server) because this mechanism is not related to IPA domain at all. +Example: + +Forward zone: sub.example.com +Zone: example.com + +Forwarding will not work, because server thinks it is authoritative +and returns NXDOMAIN + +Adding record: sub.example.com NS nameserver.out.of.ipa.domain. Again, this is not related to IPA domain at all. I propose this text: Adding record: sub.example.com NS ns.sub.example.com. +will delegate authority to another server, and IPA DNS server will +forward DNS queries. + +:param fwzonename: forwardzone +:return: None if effective, name of authoritative zone otherwise + +assert isinstance(fwzonename, DNSName) + +# get all zones +zones = api.Command.dnszone_find(pkey_only=True, + sizelimit=0)['result'] Ooooh, are you serious? :-) I don't like this approach, I would rather chop left-most labels from name and so dnszone_find() one by one. What if you have many DNS zones? This could be thrown away if you iterate only over relevant zones. +zonenames = [zone['idnsname'][0].make_absolute() for zone in zones] +zonenames.sort(reverse=True, key=len) # sort, we need longest match + +# check if is there a zone which can cause the forward zone will +# be ineffective +sub_of_auth_zone = None +for name in zonenames: +if fwzonename.is_subdomain(name): +sub_of_auth_zone = name +break + +if sub_of_auth_zone is None: +return None + +# check if forwardzone is delegated in authoritative zone +# test if exists and get NS record +try: +ns_records = api.Command.dnsrecord_show( +sub_of_auth_zone, fwzonename,
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On Wed, 10 Dec 2014 15:13:30 +0100 Petr Spacek pspa...@redhat.com wrote: I think that external DNS could depend on Vault (assuming that external DNS support will be purely optional). TBH, I do not think this is a sensible option, the Vault will drag huge dependencies for now, and I would like to avoid that if all we need is to add a couple of A/SRV records to an external DNS. If we can't come up with a service, I think I am ok telling admins they need to manually copy the TKEY (or use puppet or other similar configuration manager to push the key file around) on each replica, and we defer automatic distribution of TKEYs. We will have a service that can give out keys, it is identified as necessary in the replica promotion proposal, so we'll eventually get there. Simo. -- 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 0168] Better workaround to get status of CA during upgrade
Dne 10.12.2014 v 18:01 Jan Cholasta napsal(a): Dne 1.12.2014 v 16:48 Martin Basti napsal(a): On 01/12/14 08:46, Jan Cholasta wrote: Hi, Dne 27.11.2014 v 14:24 Martin Basti napsal(a): Ticket: https://fedorahosted.org/freeipa/ticket/4676 Replaces current workaround. Should go to 4.1.3. Patch attached. When constructing URLs with host:port, please use ipautil.format_netloc(). wget should be added as a dependency of freeipa-python in the spec file. Honza Updated patch attached. Thanks, ACK. Pushed to: master: 337faf506462a01c6dbcd00f2039ed5627691864 ipa-4-1: 5052af773f652bc19e91fe49e15351e5c5c7d976 It turns out I messed up the review (sorry). This fixes the upgrade, but it also breaks ipa-server-install: 2014-12-10T06:06:44Z DEBUG [8/27]: starting certificate server instance 2014-12-10T06:06:44Z DEBUG Starting external process 2014-12-10T06:06:44Z DEBUG args='/bin/systemctl' 'start' 'pki-tomcatd.target' 2014-12-10T06:06:45Z DEBUG Process finished, return code=0 2014-12-10T06:06:45Z DEBUG stdout= 2014-12-10T06:06:45Z DEBUG stderr= 2014-12-10T06:06:45Z DEBUG Starting external process 2014-12-10T06:06:45Z DEBUG args='/bin/systemctl' 'is-active' 'pki-tomcatd.target' 2014-12-10T06:06:45Z DEBUG Process finished, return code=0 2014-12-10T06:06:45Z DEBUG stdout=active 2014-12-10T06:06:45Z DEBUG stderr= 2014-12-10T06:06:45Z DEBUG wait_for_open_ports: localhost [8080, 8443] timeout 300 2014-12-10T06:06:49Z DEBUG The httpd proxy is not installed, wait on local port 2014-12-10T06:06:49Z DEBUG Waiting until the CA is running 2014-12-10T06:06:49Z DEBUG Starting external process 2014-12-10T06:06:49Z DEBUG args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' 'https://vm-088.idm.lab.bos.redhat.com:8443/ca/admin/ca/getStatus' 2014-12-10T06:07:09Z DEBUG Process finished, return code=5 2014-12-10T06:07:09Z DEBUG stdout= 2014-12-10T06:07:09Z DEBUG stderr=--2014-12-10 01:06:49-- https://vm-088.idm.lab.bos.redhat.com:8443/ca/admin/ca/getStatus Resolving vm-088.idm.lab.bos.redhat.com (vm-088.idm.lab.bos.redhat.com)... 10.16.78.88 Connecting to vm-088.idm.lab.bos.redhat.com (vm-088.idm.lab.bos.redhat.com)|10.16.78.88|:8443... connected. ERROR: cannot verify vm-088.idm.lab.bos.redhat.com's certificate, issued by ‘/O=IDM.LAB.BOS.REDHAT.COM/CN=Certificate Authority’: Self-signed certificate encountered. To connect to vm-088.idm.lab.bos.redhat.com insecurely, use `--no-check-certificate'. 2014-12-10T06:07:09Z DEBUG The CA status is: check interrupted I have reopened the ticket. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0174] Show SSHFP record in CLI if contains space in fingerprint part
Hi, Dne 4.12.2014 v 15:22 Martin Basti napsal(a): SSHFP records added by nsupdate contains space in fingerprint part, this space prevent framework to show record. Fixes https://fedorahosted.org/freeipa/ticket/4789 https://fedorahosted.org/freeipa/ticket/4790 Patch attached. Thanks, ACK. Pushed to: master: b5ff0b941efad5170ff5fdda4ab05b9f1c7a2113 ipa-4-1: d229c4a1cc397cfe6adf661b6bcc8360a758248c Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 12/10/2014 9:59 PM, Petr Spacek wrote: Alternatively we can use Vault for TSIG key storage and use Vault's capability to share keys among many users. In that case we don't have problem with key distribution nor authorization. I am not convinced we should grow Vault dependency for this functionality, it requires the whole PKI machinery to be available. Many deployments do not use it though. Another possibility is to say that replica-deletion can be done only by root user or that updates to external DNS are supported only when running ipa-replica-manage as root. Why does root help? So that TSIG keys will be available on all IPA servers, regardless whether they have DNS service running or not? The point is that we need to store TSIG keys somewhere to make them available to ipa* scripts on all replica but at the same not to human-users. BTW there don't need to be any 'DNS service' if only external DNS integration is in use. It would be better to have the TSIG keys available using standard FreeIPA RBAC roles, i.e. DS ACIs so that privileged users can also use the TSIG. Or am I missing anything? Ideologically - no, it sounds fine. Technically - the problem is in implementation. We need a mechanism for secure key distribution *among users*, i.e. Vault-like functionality. I would rather not re-implement Vault just for external DNS. I think that external DNS could depend on Vault (assuming that external DNS support will be purely optional). DNSSEC key distribution is very different because it distributes keys to *servers* and there is no ACI mechanism on top of that - all DNS servers need to know all the keys anyway. So IIUC, the goal would be to put TSIG keys in the Vault and then make them available for all IPA servers? I am now not sure if the Vault as proposed can easily select a group of principals to allow reading the Vault or if it is only confined for the owner/user principal. We would need to ask Endi (CCed). I assumed that very first sentence of http://www.freeipa.org/page/V4/Password_Vault_Implementation#Vault Vault is a secure place to store data or a collection of secrets. A vault may be privately owned by a user, or shared among users, groups, or services. is correct :-) Endi, we would like to have one secret which is shared among services users at the same time. Is it possible to do that with Vault? Yes, the access to a particular vault is limited to the vault members owners which can be a set of users, groups, and/or services. See http://www.freeipa.org/page/V4/Password_Vault_Implementation#Access_Control A vault member can list, archive, and retrieve the secrets in a standard vault. With symmetric vault the member will need a vault password in order to archive and retrieve secrets. With asymmetric vault the member can only archive the secrets but not retrieve them since it only has the public key and not the private key. A vault owner can list, archive, and retrieve the secrets like vault members, but it has the private key so it can retrieve secrets from asymmetric vault. The owner can also manage the list of members and owners of the vault, and change the vault password/keys. There are commands to manage the members/owners. See http://www.freeipa.org/page/V4/Password_Vault_Implementation#Adding_vault_member $ ipa vault-add-member MyVault --groups group1,group2 $ ipa vault-add-owner MyVault --users user1,user2 (we may need a separate option for services) Below are the vault LDAP ACIs. See http://www.freeipa.org/page/V4/Password_Vault_Implementation#Access_Control_Attributes aci: (targetfilter=(objectClass=ipaVault)) (targetattr=*) (version 3.0; acl Vault members can access the vault; allow(read, search, compare) userattr=member#USERDN;) aci: (targetfilter=(objectClass=ipaVault)) (targetattr=*) (version 3.0; acl Indirect vault members can access the vault; allow(read, search, compare) userattr=member#GROUPDN;) aci: (targetfilter=(objectClass=ipaVault)) (targetattr=*) (version 3.0; acl Vault owners can modify the vault; allow(read, search, compare, write) userattr=owner#USERDN;) aci: (targetfilter=(objectClass=ipaVault)) (targetattr=*) (version 3.0; acl Indirect vault owners can modify the vault; allow(read, search, compare, write) userattr=owner#GROUPDN;) Note that the secrets are stored separately in KRA, not in the IPA LDAP tree, so they are not directly controlled by the above ACIs. The vault service will first verify that you have access to the vault based on the above ACIs then it will let you archive/retrieve secrets in KRA. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0040] Remove dependency on subscription-manager
Updated patch attached.
Thanks,
Gabe
On Wed, Dec 10, 2014 at 8:02 AM, Martin Basti mba...@redhat.com wrote:
On 10/12/14 15:45, Gabe Alford wrote:
Hello,
Fix for https://fedorahosted.org/freeipa/ticket/4783
Thanks,
Gabe
Hello, thanks for patch.
The patch needs rebase for IPA-4-1 branch
Martin^2
--
Martin Basti
From 0b615dedc9e78c2922e23e0673650c53fca5fb6f Mon Sep 17 00:00:00 2001
From: Gabe redhatri...@gmail.com
Date: Wed, 10 Dec 2014 20:58:19 -0700
Subject: [PATCH] Remove dependency on subscription-manager
https://fedorahosted.org/freeipa/ticket/4783
---
freeipa.spec.in | 3 ---
1 file changed, 3 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 39166057ecd0d5a4bacef4e79bed49135f72fff4..d5231244ee7c8b0eb9edc75394e9d8a98d027d34 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -138,9 +138,6 @@ Requires: pki-ca = 10.1.2-4
%else
Requires: pki-ca = 10.2.1-0.1
%endif
-%if 0%{?rhel}
-Requires: subscription-manager
-%endif
Requires(preun): python systemd-units
Requires(postun): python systemd-units
Requires: python-dns = 1.11.1
--
2.1.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] drop archeological feature :)
ACK, works fine (in other words, removal does not break anything I could detect). Pushed to master: 8822be36d342c2bc499937c3f144e11ae98d8e58 On 11/24/2014 07:10 PM, Simo Sorce wrote: Getting through krbinstancepy I discovered we are still doing this thing with the master key that has been unnecessary for a few years now. Stop doing that. I haven't really tested this yet ... but ... what could possibly go wrong ? :-D Simo. ___ 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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0677 test_integration: Use python-pytest-multihost
On 12/09/2014 05:42 PM, Petr Viktorin wrote:
On 11/26/2014 04:18 PM, Petr Viktorin wrote:
Hello,
I have split FreeIPA's multi-host testing infrastructure into a separate
project. It is temoprarily available at:
https://github.com/encukou/pytest-multihost
and I will move it to fedorahosted as soon as it's approved:
https://fedorahosted.org/fedora-infrastructure/ticket/4605
RPMs for Fedora 20..rawhide and EPEL 7 are available in COPR:
https://copr.fedoraproject.org/coprs/pviktori/pytest-plugins/
This patch contains the necessary changes to FreeIPA. The tests
themselves are almost unchanged. FreeIPA specific parts (most
importantly, logging and environ-based configuration) are also left in.
Hi Tomáš! Thanks for testing the patch and finding a problem in the
pytest-multihost library. It is now solved.
I'm also attaching two smaller patches that fix bugs in the pytest port.
Thank you for fixing the reported issues. This version works fine, ACK
from me.
Pushed to master: a97d61df040111b9ce4585db262ddfaba24df4da
Also pushed attached one-liner to bump the Requires for python-multihost:
Pushed to master: 3e406f9924428e638dd37d2b43f6c349f1ce36e8
--
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From e9079b024df9a03beee0405a3edcef20980b44b0 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Thu, 11 Dec 2014 06:32:42 +0100
Subject: [PATCH] ipatests: Increase required version for pytest-multihost
plugin
---
freeipa.spec.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index f4218d4098204403aa86a66070439be3724461db..e8a8741c28e732077a02f5b0d515ee36bb256dd6 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -310,7 +310,7 @@ Requires: pytest = 2.6
Requires: python-paste
Requires: python-coverage
Requires: python-polib
-Requires: python-pytest-multihost = 0.2
+Requires: python-pytest-multihost = 0.4
Conflicts: %{alt_name}-tests
Obsoletes: %{alt_name}-tests %{version}
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
