[Freeipa-devel] Announcing bind-dyndb-ldap version 2.6
The FreeIPA team is proud to announce bind-dyndb-ldap version 2.6. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/. The new version has also been built for Fedora 18 and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-2.6-1.fc18,bind-9.9.2-9.P1.fc18 This release includes only bug fixes, no new features. == Changes in 2.6 == [1] Invalid zones are automatically reloaded after each change in zone data. https://fedorahosted.org/bind-dyndb-ldap/ticket/102 [2] Plugin periodically reconnects when KDC is unavailable. https://fedorahosted.org/bind-dyndb-ldap/ticket/100 [3] Invalid wildcard name in update-policy no longer crashes BIND. https://fedorahosted.org/bind-dyndb-ldap/ticket/108 [4] Crash caused by idnsAllowSyncPTR attribute in global configuration object in LDAP was fixed. https://fedorahosted.org/bind-dyndb-ldap/ticket/110 [5] Crash caused by invalid query/transfer policy was fixed. https://fedorahosted.org/bind-dyndb-ldap/ticket/109 [6] Crash caused by 'zonesub' match-type in update ACL was fixed. https://fedorahosted.org/bind-dyndb-ldap/ticket/111 [7] Support for update-policy match type 'external' was added. [8] Various improvements related to logging. == Upgrading == An server can be upgraded simply by installing updated rpms. BIND has to be restarted manually after the RPM installation. Downgrading back to any 2.x version is supported. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr Spacek Software engineer Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 391-395 Fedora 19 build and install fixes
On Tue 26 Mar 2013 06:49:59 PM CET, Martin Kosek wrote: On 03/26/2013 06:32 PM, Tomas Babej wrote: On 03/26/2013 05:38 PM, Martin Kosek wrote: On 03/21/2013 11:59 AM, Martin Kosek wrote: This set of patches (details in commit messages) allow build and installation of FreeIPA in Fedora 19. I tested server and replica install (master on f18, replica on f19) and both worked fine. The patches are compatible with Fedora 18 (I tested). If your Fedora 19 does not have bind-9.9.2-11.P1.fc19, you may need to get that from koji: Bug 920713 - named timeouts when started via systemd Also, to fix trusts and ipa-adtrust-install, I had to use my custom build of 389-ds-base as current builds do not accepts Kerberos tickets greater than 2048 bytes. This is the bug I filed: Bug 923879 - 389-ds-base cannot handle Kerberos tickets with PAC Martin Sending rebased patches (there was a conflic in spec changelog). Martin This still needs the following rebase (changelog is not in chronological order): -* Wed Mar 13 2013 Martin Kosek mko...@redhat.com - 3.1.99-2 +* Tue Mar 26 2013 Martin Kosek mko...@redhat.com - 3.1.99-2 Right, I will fix that. The build on F19 went OK, however, IPA installation on F19 fails with the following error: [snip] Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/20]: creating certificate server user [2/20]: configuring certificate server instance Unexpected error - see /var/log/ipaserver-install.log for details: IOError: [Errno 2] No such file or directory: '/root/.pki/pki-tomcat/ca_admin_cert.p12' What pki-ca version do you use? There were some related fixes for bugs I found in pki-ca component (see Bug 919476). I used pki-ca-10.0.1-2.1.fc19.noarch The version is the same. If you have this version or higher, what is the root cause of the failure? Is there any useful info in ipaserver-install.log? I haven't been able to identify the cause. There seems to be an issue with certmonger as well, since consenquent uninstallation fails with: $ sudo ipa-server-install --uninstall -U Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Unexpected error - see /var/log/ipaserver-uninstall.log for details: CalledProcessError: Command '/bin/systemctl start certmonger.service' returned non-zero exit status 1 Looking at systemctl status certmonger.service, it looks like D-Bus connection problem: $ sudo service certmonger status Redirecting to /bin/systemctl status certmonger.service certmonger.service - Certificate monitoring and PKI enrollment Loaded: loaded (/usr/lib/systemd/system/certmonger.service; disabled) Active: failed (Result: exit-code) since Wed 2013-03-27 10:06:08 CET; 2s ago Process: 5870 ExecStart=/usr/sbin/certmonger -S -p /var/run/certmonger.pid -n $OPTS (code=exited, status=1/FAILURE) Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com systemd[1]: Starting Certificate monitoring and PKI enrollment... Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com certmonger[5870]: 2013-03-27 10:06:08 [5870] Error connecting to system bus. Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com certmonger[5870]: Error connecting to D-Bus. Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com systemd[1]: certmonger.service: main process exited, code=exited, status=1/FAILURE Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com systemd[1]: Failed to start Certificate monitoring and PKI enrollment. Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com systemd[1]: Unit certmonger.service entered failed state Relevant part of the log (we already went through it with Martin, but maybe somebody has some additional insight). 2013-03-26T17:03:06Z DEBUG Starting external process 2013-03-26T17:03:06Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmp4CgKef 2013-03-26T17:03:19Z DEBUG Process finished, return code=0 2013-03-26T17:03:19Z DEBUG stdout= 2013-03-26T17:03:19Z DEBUG stderr=Job for pki-tomcatd@pki-tomcat.service failed. See 'systemctl status pki-tomcatd@pki-tomcat.service' and 'journalctl -xn' for details. *sys-package-mgr*: processing new jar, '/usr/share/java/jython.jar' *sys-package-mgr*: processing new jar, '/usr/share/java/jakarta-oro.jar' [snip] *sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/ext/pulse-java.jar' Mar 26, 2013 6:03:19 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect INFO: I/O exception (org.mozilla.jss.ssl.SSLSocketException) caught when connecting to the target host: Unable to connect: (-5961) TCP connection reset by peer. Mar 26, 2013 6:03:19 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect INFO: Retrying connect INFO: I/O exception (org.mozilla.jss.ssl.SSLSocketException) caught when connecting to the target host: Unable to connect: (-5961) TCP connection reset by peer. Mar 26, 2013 6:03:19 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect INFO: Retrying connect Mar
Re: [Freeipa-devel] [PATCH] 0100 Enumerate UPN suffixes in ipasam
On Mon, Mar 25, 2013 at 08:07:44PM +0200, Alexander Bokovoy wrote:
Hi,
following patch allows to enumerate UPN suffixes associated with IPA
domain and make them available to AD domain we trust.
The patch relies on PASSDB API expansion I'm working on and as such
requires Samba built with the change. You can find F18 scratch build at
http://koji.fedoraproject.org/koji/taskinfo?taskID=5168969, these
patches will be submitted to Samba upstream this week.
In the patch I'm filtering out our own DNS domain since its value will
be added by Samba by default -- if PASSDB module does not provide the
function, its absence will be ignored in the new API. Filtering out is
done by freeing the string and moving empty item to last position in the
array, reducing the array size but not resizing it -- talloc will hardly
win anything from resizing one (char *) pointer and actual lifetime of
the array is until the packet is sent so it is acceptable.
In order to test the patch, you need updated Samba, then rebuild FreeIPA
packages. Once installed and configured, UPN suffixes can be managed via
'ipa realmdomains-mod --{add,dell}-domain' commands. These domains will
be exposed to Windows.
When you added realm domains, an attempt to establish trust will cause
Windows to ask for name suffixes and Samba will serve expanded list of
them via netr_GetTrustInformation (opnum 44). In Samba code I've also
implemented partially opnum 43 which is giving out the same information
via DsRGetTrustInformation but so far Windows AD DC haven't actually
tried to use opnum 43.
Additionally, you can request Windows to update list of name suffixes
via UI. Here is how it looks in Windows 2012 Server:
http://abbra.fedorapeople.org/.paste/win2012-multiple-suffixes.png
Part of ticket https://fedorahosted.org/freeipa/ticket/2848
I've tested the attached patch with the samba packages mentioned above
and everything works as expect.
As can be seen in the figure Alexander linked above the new suffixes are
disabled by default on the Windows side. This is expected and exactly
the same behaviour can be found in AD-AD trusts. Nevertheless it would
be good if you can make sure this behaviour is explicitly mentioned e.g.
in the design page or other documents to avoid confusion when this
feature is tested by others.
Review comments are in-line.
bye,
Sumit
--
/ Alexander Bokovoy
From f400d55eaec99b3e5440e90b6a6d055e26529e7e Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Fri, 22 Mar 2013 17:30:41 +0200
Subject: [PATCH 2/2] ipasam: add enumeration of UPN suffixes based on the
realm domains
PASSDB API in Samba adds support for specifying UPN suffixes. The change
in ipasam will allow to pass through list of realm domains as UPN suffixes
so that Active Directory domain controller will be able to recognize
non-primary UPN suffixes as belonging to IPA and properly find our KDC
for cross-realm TGT.
Since Samba already returns primary DNS domain separately, filter it out
from list of UPN suffixes.
Also enclose provider of UPN suffixes into #ifdef to support both
Samba with and without pdb_enum_upn_suffixes().
Part of https://fedorahosted.org/freeipa/ticket/2848
---
daemons/configure.ac | 10 +++
daemons/ipa-sam/ipa_sam.c | 172
--
2 files changed, 177 insertions(+), 5 deletions(-)
diff --git a/daemons/configure.ac b/daemons/configure.ac
index d3b6b19..14dc04e 100644
--- a/daemons/configure.ac
+++ b/daemons/configure.ac
@@ -252,6 +252,16 @@ AC_CHECK_LIB([wbclient],
[$SAMBA40EXTRA_LIBPATH])
AC_SUBST(WBCLIENT_LIBS)
+AC_CHECK_LIB([pdb],
+ [make_pdb_method],
+ [HAVE_LIBPDB=1],
+ [AC_MSG_ERROR([libpdb does not have make_pdb_method])],
+ [$SAMBA40EXTRA_LIBPATH])
+AC_CHECK_LIB([pdb],[pdb_enum_upn_suffixes],
+ [AC_DEFINE([HAVE_PDB_ENUM_UPN_SUFFIXES], [1], [Ability to
enumerate UPN suffixes])],
+ [AC_MSG_WARN([libpdb does not have pdb_enum_upn_suffixes, no
support for realm domains in ipasam])],
+ [$SAMBA40EXTRA_LIBPATH])
any reason for the extra space in the indentation?
+
dnl
---
dnl - Check for check unit test framework http://check.sourceforge.net/
dnl
---
...
+static char **get_attribute_values(TALLOC_CTX *mem_ctx, LDAP *ldap_struct,
+LDAPMessage *entry, const char *attribute,
int *num_values)
+{
+ struct berval **values;
+ int count, i;
+ char **result = NULL;
+ size_t conv_size;
+
+ if (attribute == NULL || entry == NULL) {
+ return NULL;
+ }
+
+ values = ldap_get_values_len(ldap_struct, entry, attribute);
+ if (values == NULL) {
+
Re: [Freeipa-devel] [PATCH] 0100 Enumerate UPN suffixes in ipasam
Hi,
On Wed, 27 Mar 2013, Sumit Bose wrote:
Additionally, you can request Windows to update list of name suffixes
via UI. Here is how it looks in Windows 2012 Server:
http://abbra.fedorapeople.org/.paste/win2012-multiple-suffixes.png
Part of ticket https://fedorahosted.org/freeipa/ticket/2848
I've tested the attached patch with the samba packages mentioned above
and everything works as expect.
As can be seen in the figure Alexander linked above the new suffixes are
disabled by default on the Windows side. This is expected and exactly
the same behaviour can be found in AD-AD trusts. Nevertheless it would
be good if you can make sure this behaviour is explicitly mentioned e.g.
in the design page or other documents to avoid confusion when this
feature is tested by others.
I'll add that, thanks for reminding.
Review comments are in-line.
bye,
Sumit
--
/ Alexander Bokovoy
From f400d55eaec99b3e5440e90b6a6d055e26529e7e Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Fri, 22 Mar 2013 17:30:41 +0200
Subject: [PATCH 2/2] ipasam: add enumeration of UPN suffixes based on the
realm domains
PASSDB API in Samba adds support for specifying UPN suffixes. The change
in ipasam will allow to pass through list of realm domains as UPN suffixes
so that Active Directory domain controller will be able to recognize
non-primary UPN suffixes as belonging to IPA and properly find our KDC
for cross-realm TGT.
Since Samba already returns primary DNS domain separately, filter it out
from list of UPN suffixes.
Also enclose provider of UPN suffixes into #ifdef to support both
Samba with and without pdb_enum_upn_suffixes().
Part of https://fedorahosted.org/freeipa/ticket/2848
---
daemons/configure.ac | 10 +++
daemons/ipa-sam/ipa_sam.c | 172 --
2 files changed, 177 insertions(+), 5 deletions(-)
diff --git a/daemons/configure.ac b/daemons/configure.ac
index d3b6b19..14dc04e 100644
--- a/daemons/configure.ac
+++ b/daemons/configure.ac
@@ -252,6 +252,16 @@ AC_CHECK_LIB([wbclient],
[$SAMBA40EXTRA_LIBPATH])
AC_SUBST(WBCLIENT_LIBS)
+AC_CHECK_LIB([pdb],
+ [make_pdb_method],
+ [HAVE_LIBPDB=1],
+ [AC_MSG_ERROR([libpdb does not have make_pdb_method])],
+ [$SAMBA40EXTRA_LIBPATH])
+AC_CHECK_LIB([pdb],[pdb_enum_upn_suffixes],
+ [AC_DEFINE([HAVE_PDB_ENUM_UPN_SUFFIXES], [1], [Ability to
enumerate UPN suffixes])],
+ [AC_MSG_WARN([libpdb does not have pdb_enum_upn_suffixes, no
support for realm domains in ipasam])],
+ [$SAMBA40EXTRA_LIBPATH])
any reason for the extra space in the indentation?
No :)
+
dnl ---
dnl - Check for check unit test framework http://check.sourceforge.net/
dnl ---
...
+static char **get_attribute_values(TALLOC_CTX *mem_ctx, LDAP *ldap_struct,
+ LDAPMessage *entry, const char *attribute,
int *num_values)
+{
+ struct berval **values;
+ int count, i;
+ char **result = NULL;
+ size_t conv_size;
+
+ if (attribute == NULL || entry == NULL) {
+ return NULL;
+ }
+
+ values = ldap_get_values_len(ldap_struct, entry, attribute);
+ if (values == NULL) {
+ DEBUG(10, (Attribute [%s] not found.\n, attribute));
+ return NULL;
+ }
if ldap_get_values_len() returns NULL in the case of an error (according
to the man page), if there are no attributes, an empty array is
returned. This also means that count can be 0 below.
I ended up specifically checking count to zero and returning before
allocating values.
+#ifdef HAVE_PDB_ENUM_UPN_SUFFIXES
+static NTSTATUS ipasam_enum_upn_suffixes(struct pdb_methods *pdb_methods,
+TALLOC_CTX *mem_ctx,
+uint32_t *num_suffixes,
+char ***suffixes)
+{
+ int ret;
+ LDAPMessage *result;
+ LDAPMessage *entry = NULL;
+ int count, i;
+ char *realmdomains_dn = NULL;
+ char **domains = NULL;
+ struct ldapsam_privates *ldap_state;
+ struct smbldap_state *smbldap_state;
+ const char *attr_list[] = {
+ associatedDomain,
would you mind to #define attribute names and directory paths at the
beginning of ipa_sam.c?
Yes, I was wondering about that before. We have another places where we
use associatedDomain now. I've moved all of them to defines.
+ NULL
+ };
+
+ if ((suffixes == NULL) || (num_suffixes == NULL)) {
+ return NT_STATUS_UNSUCCESSFUL;
+ }
+
+ ldap_state = (struct ldapsam_privates *)pdb_methods-private_data;
+
Re: [Freeipa-devel] [PATCH] 0100 Enumerate UPN suffixes in ipasam
On Wed, Mar 27, 2013 at 12:53:18PM +0200, Alexander Bokovoy wrote:
Hi,
On Wed, 27 Mar 2013, Sumit Bose wrote:
Additionally, you can request Windows to update list of name suffixes
via UI. Here is how it looks in Windows 2012 Server:
http://abbra.fedorapeople.org/.paste/win2012-multiple-suffixes.png
Part of ticket https://fedorahosted.org/freeipa/ticket/2848
I've tested the attached patch with the samba packages mentioned above
and everything works as expect.
As can be seen in the figure Alexander linked above the new suffixes are
disabled by default on the Windows side. This is expected and exactly
the same behaviour can be found in AD-AD trusts. Nevertheless it would
be good if you can make sure this behaviour is explicitly mentioned e.g.
in the design page or other documents to avoid confusion when this
feature is tested by others.
I'll add that, thanks for reminding.
Review comments are in-line.
bye,
+
+ /* Since associatedDomain has attributeType MUST, there must be at
least one domain */
+ for (i = 0; i count ; i++) {
+ if (strcmp(ldap_state-domain_name, domains[i]) == 0) {
+ break;
+ }
+ }
Since we area handling DNS domain names here strcasecmp() would be more
fault tolerant? OTOH I think mixed cases here can only happen if some
modifies IPA LDAP object manually.
Technically it should be something that does utf-8 caseless lookups. We
can go with strcasecmp as it is for time being, I'll add TODO there for
future IDN handling.
yes, good idea
New patch attached. Survives Windows 2012 testing.
Survives my testing with 2008 as well. ACK.
bye,
Sumit
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0010 Add mkhomedir option to ipa-server-install and ipa-replica-install
On Wed 27 Mar 2013 01:54:49 PM CET, Ana Krivokapic wrote: On 03/27/2013 12:15 PM, Tomas Babej wrote: On 03/26/2013 07:45 PM, Ana Krivokapic wrote: Add the option to create home directories for users on their first login to ipa-server-install and ipa-replica-install. https://fedorahosted.org/freeipa/ticket/3515 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK from the functional point of view. Just a nitpick, can you please reformat the patch and fix PEP8 E501 errors? I know there's a lot of PEP8 errors and warnings in the whole project (and we probably need to adress this), however, let us not introduce new ones. Tomas Fixed, thanks. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. Thanks. Updated patch works fine, ACK. Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins
On 03/26/2013 03:05 PM, Jan Cholasta wrote: On 25.3.2013 16:21, Martin Kosek wrote: On 03/25/2013 02:41 PM, Martin Kosek wrote: I checked what you have already and this is what I found: 1) Internal error if I try to remove krbticketflags via *attr functions: # ipa service-add foo/`hostname` --setattr=krbticketflags=None ipa: ERROR: an internal error has occurred # ipa service-add foo/`hostname` Added service foo/vm-037.idm.lab.bos.redhat@idm.lab.bos.redhat.com # ipa service-mod foo/`hostname` --setattr=krbticketflags=None ipa: ERROR: an internal error has occurred Fixed. 2) The RFE page needs updating, it does not reflect current reality. AFAIU, the only thing that's left to be decided is the granularity of the ACIs used to control this flag. RFE page updated. I read this part of design proposal discussion wrong, this is already decided - we do not want to have a fine grain granularity, these are too powerful flags to be delegated per-flag to lower admins. So I think that you current approach is sufficient, I do not think we need to add this attribute to some host/service related permission to avoid allowing this sensitive attribute for lower level admins automatically. If someone wants it, he can add and assign an appropriate permission. Correct, this has been already decided. Updated patch attached. Honza This looks OK. Please just also add unit tests exercising this new feature. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
Hi, On 22.3.2013 13:10, Petr Viktorin wrote: The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? I have gone through the whole discussion, RFE page and your patches, and I still don't see why --root-ca-file is necessary. Walking the certificate chain from the server cert up to the root CA is easy, so why not do that to determine the root CA? If the option is there just to ensure that the right certificate is used, I think it would be better to ask the user to confirm that during the installation process, or use --root-ca-subject or similar option to specify what certificate to use. We should do some validation of the PKCS#12 files and the certificates within them, as currently ipa-server-install will happily accept anything thrown at it. I think the minimum is to validate that the PKCS#12 file contains the whole certificate chain, the server key and only that, and that the server certificate has CN=fqdn (or CN=*.domain if we want to allow wildcard certs) in its subject. If we don't do that, ipa-server-install might fail when it's too late to fix things. Also, the RFE page states that the options to specify PKCS#12 files are called --http_pkcs and --dirsrv_pkcs, but they are in fact called --http_pkcs12 and --dirsrv_pkcs12. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] git versions for rpms in makefile
On 03/26/2013 10:41 PM, Orion Poplawski wrote: On 03/26/2013 07:36 PM, Simo Sorce wrote: On Tue, 2013-03-26 at 19:14 -0400, Rob Crittenden wrote: Orion Poplawski wrote: This patch uses the Fedora standard for git versioning (version-#.gittag) when making rpms. I'm afraid I haven't been able to test for the non-git version case. What is the purpose of this? We don't do upstream releases from developer build, so having the wrong Source0 doesn't seem like a big deal (though I'll admit no strictly correct). Sound like a reasonable improvement to me, and makes it sure you do not confuse an upstream build with a developer build, I am not so sure about using __GIT__, it's kinda annoying to type, although shell completion here helps I guess. I lean toward acking this approach, if you do not have objections Rob. Simo. My motivation for this was from testing the pkcs12 patches. First I did an srpm build and got 3.1.99GITec94138-0.fc18.src.rpm. Then I updated the git repo, did another srpm build and got 3.1.99GIT5acd43d-1.fc18.src.rpm which would have been lower EVR wise. Now I can get: 3.1.99-1.GIT5acd43d.fc18.src.rpm which would have been newer than 3.1.99-0.GITec94138.fc18.src.rpm and allowed me to do yum update. (actually, for pre-releases it should be -0.1.GIT, -0.2.GIT, ...) So it doesn't impact releases, just local developer testing - which I don't know how much is done via rpms. I think you're confusing issues. You cannot use a git hash to properly collate based on build sequence. This is why in our development builds we prefix the git hash with a timestamp. It's the timestamp which affords the proper collation, the git hash is only informative. These issues to not arise in release builds because version and or release value is incremented. But the above is independent of whether we should follow the fedora convention for git hash, that's probably a good idea, just realize it won't solve your problem of version collation. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 03:44 PM, Jan Cholasta wrote: Hi, On 22.3.2013 13:10, Petr Viktorin wrote: The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? I have gone through the whole discussion, RFE page and your patches, and I still don't see why --root-ca-file is necessary. Walking the certificate chain from the server cert up to the root CA is easy, so why not do that to determine the root CA? If the option is there just to ensure that the right certificate is used, I think it would be better to ask the user to confirm that during the installation process, or use --root-ca-subject or similar option to specify what certificate to use. Well, --root-ca-file specifies the root of trust, not necessarily the selfsigned/unsigned CA at end of the trust chain. Suppose you have a company-wide cert signed by a globally trusted CA, but you're paranoid only want to trust the company cert, not a CA that signs half the world's certificates. In that case walking up the chain would select the wrong certificate. Please correct me if my thinking is wrong. Yes, a --root-ca-subject would work too. I assumed the PEM file is readily available. We should do some validation of the PKCS#12 files and the certificates within them, as currently ipa-server-install will happily accept anything thrown at it. I think the minimum is to validate that the PKCS#12 file contains the whole certificate chain, the server key and only that, and that the server certificate has CN=fqdn (or CN=*.domain if we want to allow wildcard certs) in its subject. If we don't do that, ipa-server-install might fail when it's too late to fix things. I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? If there is I can put it in, but I don't want to re-create the validation. The code checks for the whole cert chain, and that's there only one server cert. Does that not work? Also, the RFE page states that the options to specify PKCS#12 files are called --http_pkcs and --dirsrv_pkcs, but they are in fact called --http_pkcs12 and --dirsrv_pkcs12. Fixed, thanks. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. Finding time to work on python-nss has been a problem. This is further complicated by the fact Mozilla has changed from CVS to Mercurial while I had this code in development and I haven't moved over to the new distributed SCM yet. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 271, 272 Added Web UI support for service PAC type option: NONE
On 3/26/2013 12:55 PM, Endi Sukma Dewata wrote: On 3/25/2013 6:46 AM, Petr Vobornik wrote: Reimplemented ^^ to match your proposal. Attaching as patches with new numbers (271,272) as they don't have much common with the original patch. The code looks good. Do you have a static/live demo site? After some testing, ACK. One minor thing (and you already documented this behavior), suppose initially you override the PAC types, then you change to inherit the settings, then you switch back to override, the checkboxes aren't restored. Yes, there's an undo/reset button, but it would be nice if we can preserve the checkboxes (by disabling them but keep the selection) even if the radio button isn't selected. Then if we save the changes, the disabled checkboxes can be completely cleared. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 04:40 PM, Jan Cholasta wrote: On 27.3.2013 16:23, Petr Viktorin wrote: On 03/27/2013 03:44 PM, Jan Cholasta wrote: I have gone through the whole discussion, RFE page and your patches, and I still don't see why --root-ca-file is necessary. Walking the certificate chain from the server cert up to the root CA is easy, so why not do that to determine the root CA? If the option is there just to ensure that the right certificate is used, I think it would be better to ask the user to confirm that during the installation process, or use --root-ca-subject or similar option to specify what certificate to use. Well, --root-ca-file specifies the root of trust, not necessarily the selfsigned/unsigned CA at end of the trust chain. Suppose you have a company-wide cert signed by a globally trusted CA, but you're paranoid only want to trust the company cert, not a CA that signs half the world's certificates. In that case walking up the chain would select the wrong certificate. Please correct me if my thinking is wrong. Makes sense, thanks. Can you please put this information in the RFE page? Added. Yes, a --root-ca-subject would work too. I assumed the PEM file is readily available. Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... Well, if the PKCS#12 only has the server cert that's signed directly by the CA, there's no duplication. This is arguably the common case. Honestly, I don't know what would be easier for a typical sysadmin in an organization that needs this functionality. These two approaches seem pretty even to me. We should do some validation of the PKCS#12 files and the certificates within them, as currently ipa-server-install will happily accept anything thrown at it. I think the minimum is to validate that the PKCS#12 file contains the whole certificate chain, the server key and only that, and that the server certificate has CN=fqdn (or CN=*.domain if we want to allow wildcard certs) in its subject. If we don't do that, ipa-server-install might fail when it's too late to fix things. I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? If there is I can put it in, but I don't want to re-create the validation. I'm not sure TBH. Maybe someone with more NSS experience could answer this? The code checks for the whole cert chain, and that's there only one server cert. Does that not work? Actually I didn't check this specifically. But, I used a server certificate with wrong subject and that made ipa-server-install fail. I'll see how python-nss can help here. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 05:09 PM, Rob Crittenden wrote: [...] Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... We're talking a one-time operation. I don't think it's asking too much. It also gives the user some amount of control rather than assuming that whatever tool their using to create the PKCS#12 file is also smart enough to include the right CAs. Well, to be fair, if there are any intermediate CAs, they need to be in the PKCS#12. (In the future there may be support for multiple root CAs, which would all get explicit trust. Those would all go in the PEM, so intermediate ones must be somewhere else -- in the PKCS#12.) Anyway I think it's unlikely that everybody will have the certs in the right format for IPA by default, whatever that format is. Honza has a point, but... If one solution is clearly better (in terms of best/common practices in organizations this feature is for), I'm happy to change it. Otherwise let's paint the bikeshed with the color I have ready :) [...] I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? If there is I can put it in, but I don't want to re-create the validation. I'm not sure TBH. Maybe someone with more NSS experience could answer this? certutil -V -u V will do it. The usage is already checked -- and with this command, too :) The problem here is hostname validation. I don't think it would be onerous to assure that either the FQDN is in the CN or it is a '*'. python-nss has fairly easy ways to grab the subject out of a cert for this comparison. The code checks for the whole cert chain, and that's there only one server cert. Does that not work? Actually I didn't check this specifically. But, I used a server certificate with wrong subject and that made ipa-server-install fail. One of the many cases that we will need to handle. I found that python-nss has a verify_hostname call. I'll add it. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 04:40 PM, John Dennis wrote: On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Thanks! I'll take a look at it again. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. I'll add verify_hostname from the validation example; if there's anything else please give me a pointer -- I haven't read all the docs, yet. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 12:42 PM, Petr Viktorin wrote: On 03/27/2013 05:09 PM, Rob Crittenden wrote: [...] Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... We're talking a one-time operation. I don't think it's asking too much. It also gives the user some amount of control rather than assuming that whatever tool their using to create the PKCS#12 file is also smart enough to include the right CAs. Well, to be fair, if there are any intermediate CAs, they need to be in the PKCS#12. (In the future there may be support for multiple root CAs, which would all get explicit trust. Those would all go in the PEM, so intermediate ones must be somewhere else -- in the PKCS#12.) Anyway I think it's unlikely that everybody will have the certs in the right format for IPA by default, whatever that format is. Honza has a point, but... If one solution is clearly better (in terms of best/common practices in organizations this feature is for), I'm happy to change it. Otherwise let's paint the bikeshed with the color I have ready :) [...] I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? If there is I can put it in, but I don't want to re-create the validation. I'm not sure TBH. Maybe someone with more NSS experience could answer this? certutil -V -u V will do it. The usage is already checked -- and with this command, too :) The problem here is hostname validation. I don't think it would be onerous to assure that either the FQDN is in the CN or it is a '*'. python-nss has fairly easy ways to grab the subject out of a cert for this comparison. The code checks for the whole cert chain, and that's there only one server cert. Does that not work? Actually I didn't check this specifically. But, I used a server certificate with wrong subject and that made ipa-server-install fail. One of the many cases that we will need to handle. I found that python-nss has a verify_hostname call. I'll add it. It also has Certificate.verify_now(). There are examples of usage in either the doc/examples directory or the test directory. NB, the cert has to be in the database, a possible limitation for the intended usage. The enhanced unreleased code dispenses with that restriction and adds additional functionality. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 12:44 PM, Petr Viktorin wrote: On 03/27/2013 04:40 PM, John Dennis wrote: On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Thanks! I'll take a look at it again. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. I'll add verify_hostname from the validation example; if there's anything else please give me a pointer -- I haven't read all the docs, yet. doc/examples/verify_server.py test/test_client_server.py illustrate example usage. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 110 Add support for cmocka C-Unit Test framework
Hi, this patch does not do anything really useful for now, it just adds configure checks. The related ticket https://fedorahosted.org/freeipa/ticket/3434 is in the current milestone but it can easily deferred to a later milestone if you do not have the time to review it. bye, Sumit From 8fd76e4b6f911243aa17b73910348c2b4c4bcd7b Mon Sep 17 00:00:00 2001 From: Sumit Bose sb...@redhat.com Date: Wed, 27 Mar 2013 18:00:29 +0100 Subject: [PATCH] Add support for cmocka C-Unit Test framework cmocka is a more advanced unit test framework for C-code than the currently used check framework. This patch adds configure checks and makefile variables so that new unit tests can use cmocka. Fixes https://fedorahosted.org/freeipa/ticket/3434 --- daemons/configure.ac | 31 +++ 1 file changed, 31 insertions(+) diff --git a/daemons/configure.ac b/daemons/configure.ac index 0eb064665623f0406d88b3d7c019661505650bbe..3e8e81f5e3fa278347c1990ff2d831216e4e5eb3 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -273,6 +273,37 @@ else fi AM_CONDITIONAL([HAVE_CHECK], [test x$have_check != x]) +dnl --- +dnl - Check for cmocka unit test framework http://cmocka.cryptomilk.org/ +dnl This will be simplified when cmocka carries a .pc file. +dnl --- +AC_SUBST(CMOCKA_LIBS) +AC_SUBST(CMOCKA_CFLAGS) + +AC_CHECK_HEADERS( +[setjmp.h cmocka.h],,, +[[ #include stdarg.h + # include stddef.h + #ifdef HAVE_SETJMP_H + # include setjmp.h + #endif +]] +) + +if test x$ac_cv_header_setjmp_h = xyes test x$ac_cv_header_cmocka_h = xyes ; then +AC_CHECK_LIB([cmocka], [_will_return], + [ CMOCKA_LIBS=-lcmocka + AC_MSG_RESULT([libcmocka available, cmocka tests will be build]) + have_cmocka=yes ], + [AC_MSG_WARN([No libcmocka library found, cmocka tests will not be build]) + have_cmocka=no ]) +else +AC_MSG_WARN([Required header files for libcmocka are missing, cmocka tests will not be build]) +have_cmocka=no +fi + +AM_CONDITIONAL([HAVE_CMOCKA], [test x$have_cmocka = xyes]) + dnl -- dirsrv is needed for the extdom unit tests -- PKG_CHECK_MODULES([DIRSRV], [dirsrv = 1.3.0]) dnl -- sss_idmap is needed by the extdom exop -- -- 1.8.1.4 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 10:42 AM, Petr Viktorin wrote: On 03/27/2013 05:09 PM, Rob Crittenden wrote: [...] Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... We're talking a one-time operation. I don't think it's asking too much. It also gives the user some amount of control rather than assuming that whatever tool their using to create the PKCS#12 file is also smart enough to include the right CAs. Well, to be fair, if there are any intermediate CAs, they need to be in the PKCS#12. (In the future there may be support for multiple root CAs, which would all get explicit trust. Those would all go in the PEM, so intermediate ones must be somewhere else -- in the PKCS#12.) Anyway I think it's unlikely that everybody will have the certs in the right format for IPA by default, whatever that format is. Honza has a point, but... If one solution is clearly better (in terms of best/common practices in organizations this feature is for), I'm happy to change it. Otherwise let's paint the bikeshed with the color I have ready :) FWIW (about $0.02), it did take me a while to figure out how to create pkcs12 files that included the CA certificate chain out of the PEM files given to me by my CA that ipa needed. Might be nice to have that in docs somewhere. But I can live with this color of bikeshed :) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
