From ldoudova at redhat.com Mon Aug 1 06:20:05 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 1 Aug 2016 08:20:05 +0200 Subject: [Freeipa-devel] [PATCH 0030][Tests] Fix authentication indicators tests failing due to removal of has_keytab key from list of expected attributes of update command Message-ID: <06c4c43a-b2d7-5a45-d993-c6ce48273389@redhat.com> Hi, solution for https://fedorahosted.org/freeipa/ticket/5281 has removed has_keytab attribute from list of expected keys of service-mod command. Attached patch provides a fix for tests that consequently started to fail. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0030-Tests-Remove-has_keytab-from-list-of-expected-keys-o.patch Type: text/x-patch Size: 1346 bytes Desc: not available URL: From jcholast at redhat.com Mon Aug 1 06:27:21 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 1 Aug 2016 08:27:21 +0200 Subject: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value In-Reply-To: References: <7b729ec0-619f-17d4-bf2f-dceca268a444@redhat.com> <5467c214-4555-0d07-520f-9a280da2f7c9@redhat.com> <31ceaafa-4f54-7bcb-e7d1-1452d3eb5f30@redhat.com> <809195d1-83f7-bf47-df6b-ad2cc1851e50@redhat.com> Message-ID: <4f559de0-9e98-72d7-8844-0ae1e9ce2863@redhat.com> On 28.7.2016 16:55, Petr Spacek wrote: > On 28.7.2016 16:44, Jan Cholasta wrote: >> On 28.7.2016 16:37, Petr Spacek wrote: >>> On 28.7.2016 16:35, Jan Cholasta wrote: >>>> On 28.7.2016 16:20, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> install: Call hostnamectl set-hostname only if --hostname option is used >>>>> >>>>> This commit also splits hostname backup and configuration into two separate >>>>> functions. This allows us to backup hostname without setting it at the >>>>> same time. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6071 >>>> >>>> Note that you can set ca_host in cfg unconditionally, the value is only valid >>>> during install and is not written anywhere. >>> >>> I prefer not to set it so the code blows up when we attempt to touch variables >>> we should reference in particular setups. I.e. Take this as a first step >>> towards api.env without invalid values :-) >> >> OK. Use the proper condition then ("if setup_ca:"). > > Oh, I'm probably blind. Here is revised version. But you used "if not setup_ca:" rather than "if setup_ca:" :-) > > Petr^2 Spacek > >> >>> >>> (In my stash I have a patch which removes nonsense defaults from >>> ipalib.constants. To be pushed when we a new git branch for 4.4...) >>> >>> Petr^2 Spacek >>> >>>>> server-install: Fix --hostname option to always override api.env values >>>>> >>>>> Attempts to compare local hostname with user-provided values are error >>>>> prone as we found out in #5794. This patch removes comparison and makes >>>>> the env values deterministic. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6071 >>>>> >>>>> >>>>> Jan, this patch set should fix problems you have seen in containers. -- Jan Cholasta From ofayans at redhat.com Mon Aug 1 07:21:20 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 1 Aug 2016 09:21:20 +0200 Subject: [Freeipa-devel] [PATCH 0024][Tests] Fix integration tests not to produce incorrect /etc/hosts file In-Reply-To: References: <1c1eeea2-19f9-b4e6-bc56-204fdb888b18@redhat.com> <5773F9CC.9070902@redhat.com> Message-ID: <579EF870.2030200@redhat.com> ACK On 07/19/2016 01:19 PM, Lenka Doudova wrote: > > > On 06/29/2016 06:49 PM, Petr Spacek wrote: >> On 29.6.2016 18:39, Oleg Fayans wrote: >>> In fact, I believe /etc/hosts file should not be touched at all. >>> Hostname resolution is usually governed by the DNS system of the lab in >>> which tests are running. We do not modify it when perform tests >>> manually, so I'd rather remove this method at all. >> +1, it should not be need. Let me know if it is needed for some reason >> and I >> will have a look. >> >> Petr^2 Spacek > Hi, > > providing new (and renamed) patch as was suggested in the discussion > above - removing manipulation with /etc/hosts file from the tests. > The "fix_etc_hosts" function was completely removed from the tasks file. > Verification that nothing is broken by this change was done by running > some random integration test (trust tests), and also on Milan's > suggestion by running a test requiring two replicas (replica promotion > tests). > > Lenka > >>> On 06/29/2016 06:27 PM, Lenka Doudova wrote: >>>> Hi all, >>>> >>>> a function 'fix_etc_hosts' in ipatests/test_integration/tasks.py >>>> produces incorrect /etc/hosts file (solitary IPv6 address), and >>>> currently parser is not able to resolve the issue, causing >>>> ipa-server-install to fail with 'list index out of range' error. >>>> >>>> Hence I'm attaching patch to fix this issue before parser is fixed >>>> (related ticket to it #6014). The fix is just change of regexs >>>> responsible for creating incorrect file so that all the lines >>>> containing >>>> defined hostname are removed, not just specific IP/hostname/shortname >>>> strings. >>>> >>>> >>>> Lenka > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From jcholast at redhat.com Mon Aug 1 08:19:44 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 1 Aug 2016 10:19:44 +0200 Subject: [Freeipa-devel] [PATCHES 681-682] cert: speed up cert-find, do not crash on invalid data in cert-find Message-ID: Hi, the attached patches fix and . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-681-cert-speed-up-cert-find.patch Type: text/x-patch Size: 17836 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-682-cert-do-not-crash-on-invalid-data-in-cert-find.patch Type: text/x-patch Size: 2598 bytes Desc: not available URL: From mbasti at redhat.com Mon Aug 1 08:20:42 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Aug 2016 10:20:42 +0200 Subject: [Freeipa-devel] [PATCH 0024][Tests] Fix integration tests not to produce incorrect /etc/hosts file In-Reply-To: <579EF870.2030200@redhat.com> References: <1c1eeea2-19f9-b4e6-bc56-204fdb888b18@redhat.com> <5773F9CC.9070902@redhat.com> <579EF870.2030200@redhat.com> Message-ID: On 01.08.2016 09:21, Oleg Fayans wrote: > ACK > > On 07/19/2016 01:19 PM, Lenka Doudova wrote: >> >> >> On 06/29/2016 06:49 PM, Petr Spacek wrote: >>> On 29.6.2016 18:39, Oleg Fayans wrote: >>>> In fact, I believe /etc/hosts file should not be touched at all. >>>> Hostname resolution is usually governed by the DNS system of the >>>> lab in >>>> which tests are running. We do not modify it when perform tests >>>> manually, so I'd rather remove this method at all. >>> +1, it should not be need. Let me know if it is needed for some reason >>> and I >>> will have a look. >>> >>> Petr^2 Spacek >> Hi, >> >> providing new (and renamed) patch as was suggested in the discussion >> above - removing manipulation with /etc/hosts file from the tests. >> The "fix_etc_hosts" function was completely removed from the tasks file. >> Verification that nothing is broken by this change was done by running >> some random integration test (trust tests), and also on Milan's >> suggestion by running a test requiring two replicas (replica promotion >> tests). >> >> Lenka >> >>>> On 06/29/2016 06:27 PM, Lenka Doudova wrote: >>>>> Hi all, >>>>> >>>>> a function 'fix_etc_hosts' in ipatests/test_integration/tasks.py >>>>> produces incorrect /etc/hosts file (solitary IPv6 address), and >>>>> currently parser is not able to resolve the issue, causing >>>>> ipa-server-install to fail with 'list index out of range' error. >>>>> >>>>> Hence I'm attaching patch to fix this issue before parser is fixed >>>>> (related ticket to it #6014). The fix is just change of regexs >>>>> responsible for creating incorrect file so that all the lines >>>>> containing >>>>> defined hostname are removed, not just specific IP/hostname/shortname >>>>> strings. >>>>> >>>>> >>>>> Lenka >> >> >> > Pushed to master: a20c04033a437c5531b0ae4781d76738d1f02029 From jcholast at redhat.com Mon Aug 1 08:27:40 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 1 Aug 2016 10:27:40 +0200 Subject: [Freeipa-devel] [PATCHES 681-682] cert: speed up cert-find, do not crash on invalid data in cert-find In-Reply-To: References: Message-ID: <5fdd4314-7c3f-242d-1648-0aae521f1743@redhat.com> On 1.8.2016 10:19, Jan Cholasta wrote: > Hi, > > the attached patches fix > and . Self-NACK, proper patches attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-681.1-cert-speed-up-cert-find.patch Type: text/x-patch Size: 17908 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-682.1-cert-do-not-crash-on-invalid-data-in-cert-find.patch Type: text/x-patch Size: 2598 bytes Desc: not available URL: From gkaihoro at redhat.com Mon Aug 1 10:01:14 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Mon, 1 Aug 2016 06:01:14 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0030][Tests] Fix authentication indicators tests failing due to removal of has_keytab key from list of expected attributes of update command In-Reply-To: <06c4c43a-b2d7-5a45-d993-c6ce48273389@redhat.com> References: <06c4c43a-b2d7-5a45-d993-c6ce48273389@redhat.com> Message-ID: <735786916.48954688.1470045674425.JavaMail.zimbra@redhat.com> Greetings! ACK Best regards, Ganna Kaihorodova Associate Software Quality Engineer ----- Original Message ----- From: "Lenka Doudova" To: "freeipa-devel" Sent: Monday, August 1, 2016 8:20:05 AM Subject: [Freeipa-devel] [PATCH 0030][Tests] Fix authentication indicators tests failing due to removal of has_keytab key from list of expected attributes of update command Hi, solution for https://fedorahosted.org/freeipa/ticket/5281 has removed has_keytab attribute from list of expected keys of service-mod command. Attached patch provides a fix for tests that consequently started to fail. Lenka -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From flo at redhat.com Mon Aug 1 12:28:33 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Mon, 1 Aug 2016 14:28:33 +0200 Subject: [Freeipa-devel] [PATCH 0560] ipa-client-automount: don not initialize API during uninstall In-Reply-To: References: Message-ID: <86d3a8f3-fe5e-ee6e-d9c8-0bacc43ccc6b@redhat.com> On 07/29/2016 04:56 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/6072 > > Patch attached. > > > Hi Martin, thanks for your patch. I could not reproduce the issue anymore with ipa-client-automount --uninstall, thus looks good to me. Ack, Flo. From ldoudova at redhat.com Mon Aug 1 14:13:19 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 1 Aug 2016 16:13:19 +0200 Subject: [Freeipa-devel] [PATCH] 0078-82: webui tests: tests for new certificate widget In-Reply-To: References: <3e447bbe-fade-c5e5-2415-15ed7ae0b2ea@redhat.com> <7298654a-0ea9-8f42-dc24-f48f0dabeeb4@redhat.com> Message-ID: <4864a490-3217-8d81-8e5f-d341fef661ea@redhat.com> On 07/29/2016 03:00 PM, Pavel Vomacka wrote: > > > > On 07/28/2016 08:16 AM, Lenka Doudova wrote: >> >> >> >> On 07/20/2016 04:51 PM, Pavel Vomacka wrote: >>> Please review attached patches, which add tests for new certificate >>> widget in WebUI. >>> >>> https://fedorahosted.org/freeipa/ticket/6064 >>> >>> >>> >> Hi, >> thanks for patches. >> Functionally ok, but you have lots of PEP8 errors in patches 78, 80, >> 81 and 82 -> NACK. >> Also in patch 82, method test_arbitrary_certificate, comment says >> user needs to have "arbitrary_cert" configured, but the property in >> config file is correctly "arbitrary_cert_path", so it's a bit misleading. >> >> Patch 79 is OK, ACK. >> >> Lenka >> >> > Thank you for review. Attaching patches which have fixed all pep8 > erros. Bad property of config file was also mentioned in patch 81. > These are also fixed. > > -- > Pavel^3 Vomacka Hi, all is fine now, ACK for all patches. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdudlak at redhat.com Mon Aug 1 14:45:49 2016 From: tdudlak at redhat.com (Tibor Dudlak) Date: Mon, 1 Aug 2016 16:45:49 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method Message-ID: Hi, I have added few lines to code to make optional login with personal certificate (or with smartcard) possible. Some ui changes has to be made. It is not cosher but it definitely work. Thank you, Tibor -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tdudlak-0001-Added-new-authentication-method.patch Type: text/x-patch Size: 2041 bytes Desc: not available URL: From mbasti at redhat.com Mon Aug 1 15:08:27 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Aug 2016 17:08:27 +0200 Subject: [Freeipa-devel] [PATCH] 0078-82: webui tests: tests for new certificate widget In-Reply-To: <4864a490-3217-8d81-8e5f-d341fef661ea@redhat.com> References: <3e447bbe-fade-c5e5-2415-15ed7ae0b2ea@redhat.com> <7298654a-0ea9-8f42-dc24-f48f0dabeeb4@redhat.com> <4864a490-3217-8d81-8e5f-d341fef661ea@redhat.com> Message-ID: On 01.08.2016 16:13, Lenka Doudova wrote: > > > > On 07/29/2016 03:00 PM, Pavel Vomacka wrote: >> >> >> >> On 07/28/2016 08:16 AM, Lenka Doudova wrote: >>> >>> >>> >>> On 07/20/2016 04:51 PM, Pavel Vomacka wrote: >>>> Please review attached patches, which add tests for new certificate >>>> widget in WebUI. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6064 >>>> >>>> >>>> >>> Hi, >>> thanks for patches. >>> Functionally ok, but you have lots of PEP8 errors in patches 78, 80, >>> 81 and 82 -> NACK. >>> Also in patch 82, method test_arbitrary_certificate, comment says >>> user needs to have "arbitrary_cert" configured, but the property in >>> config file is correctly "arbitrary_cert_path", so it's a bit >>> misleading. >>> >>> Patch 79 is OK, ACK. >>> >>> Lenka >>> >>> >> Thank you for review. Attaching patches which have fixed all pep8 >> erros. Bad property of config file was also mentioned in patch 81. >> These are also fixed. >> >> -- >> Pavel^3 Vomacka > Hi, > > all is fine now, ACK for all patches. > > Lenka > > master: * 26803a0d173192ee05878dd47c22a95b4432d078 Add possibility to choose parent element by css * 45825b84b0d140f62e1459c3b5dbb5281229cad6 Add function which check whether the field is empty * 37c0bd1dd6e19dd4afefb47ab52ace0a25f2ca82 TEST: managing user certificates * 20e8cef394993855fb291cb55684fe3facad82aa TEST: managing host certificates * 5f5203eb620d21244d3c39ee25ba8f093106122b TEST: managing service certificates -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Aug 1 15:15:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Aug 2016 17:15:13 +0200 Subject: [Freeipa-devel] [PATCH 0197] re-set canonical principal name on migrated users In-Reply-To: <68c315f8-1602-e0a4-5778-b3fd11e37776@redhat.com> References: <12385b87-34ee-6cf4-8a8a-f2a7ce4a85e2@redhat.com> <68c315f8-1602-e0a4-5778-b3fd11e37776@redhat.com> Message-ID: <0b0ca7bc-07b0-042a-8a0c-fe508a20f2cb@redhat.com> On 29.07.2016 15:10, Martin Basti wrote: > > > On 29.07.2016 14:42, Florence Blanc-Renaud wrote: >> On 07/28/2016 10:56 AM, Martin Babinsky wrote: >>> Fixes https://fedorahosted.org/freeipa/ticket/6101 >>> >>> I have also noticed that the principal aliases are not preserved during >>> migration from FreeIPA 4.4. >>> >>> That, however, requires more powerful runes to transform the realm of >>> all values and warrants a separate ticket if we even want to support >>> migration of user aliases. >>> >>> >>> >> Hi Martin, >> >> thanks for your patch. From a technical standpoint, it looks good to >> me as I tested the following scenarios: >> >> 1/ without --user-ignore-attribute >> - call ipa migrate-ds without specifying any attributes to ignore >> The user entries are migrated, and contain a migrated >> krbprincipalname and krbcanonicalname. >> At this point kinit fails but this is expected as the krb attributes >> were not re-generated. Login to the web https://hostname/ipa/ui also >> fails as expected. >> - login to https://hostname/ipa/migration with the user credentials >> - perform kinit => OK >> - login to https://hostname/ipa/ui => OK >> >> 2/ with --user-ignore-attribute={krbPrincipalName,krbextradata,...} >> as explained in the Migration page [1] >> At this point kinit fails as expected, as well as login to the web >> ipa/ui. >> - login to https://hostname/ipa/migration with the user credentials >> - perform kinit => OK >> - login to https://hostname/ipa/ui => OK >> >> >> But the patch produces new pep8 complaints: >> ./ipaserver/plugins/migration.py:39:1: E402 module level import not >> at top of file > > This is caused by old code, it should not prevent this patch to be > acked. Imports are heavily mixed in code already, it is not possible > to keep importing right without fixing old ones. > Martin^2 > >> >> Flo. >> >> ---- >> [1] >> https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA >> > Pushed to master: 1a04edd36bd95d0e6e8c43e742113b3e3cadfb6b From mbasti at redhat.com Mon Aug 1 15:17:11 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Aug 2016 17:17:11 +0200 Subject: [Freeipa-devel] [PATCH 0030][Tests] Fix authentication indicators tests failing due to removal of has_keytab key from list of expected attributes of update command In-Reply-To: <735786916.48954688.1470045674425.JavaMail.zimbra@redhat.com> References: <06c4c43a-b2d7-5a45-d993-c6ce48273389@redhat.com> <735786916.48954688.1470045674425.JavaMail.zimbra@redhat.com> Message-ID: On 01.08.2016 12:01, Ganna Kaihorodova wrote: > Greetings! > > ACK > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > ----- Original Message ----- > From: "Lenka Doudova" > To: "freeipa-devel" > Sent: Monday, August 1, 2016 8:20:05 AM > Subject: [Freeipa-devel] [PATCH 0030][Tests] Fix authentication indicators tests failing due to removal of has_keytab key from list of expected attributes of update command > > Hi, > > solution for https://fedorahosted.org/freeipa/ticket/5281 has removed > has_keytab attribute from list of expected keys of service-mod command. > Attached patch provides a fix for tests that consequently started to fail. > > Lenka > > Pushed to master: 63a91ca49a40590784dbc3e91001f9864f3a185e From rcritten at redhat.com Mon Aug 1 15:17:12 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 1 Aug 2016 11:17:12 -0400 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: References: Message-ID: <579F67F8.6020007@redhat.com> Tibor Dudlak wrote: > Hi, > > I have added few lines to code to make optional login with personal > certificate (or with smartcard) possible. Some ui changes has to be > made. It is not cosher but it definitely work. > > Thank you, Tibor > What about the Apache changes to require a certificate in /ipa/session/login_x509? Does/will this only support a specially crafted certificate subject? How/where does the UI get a Kerberos ticket for the user? rob From mbasti at redhat.com Mon Aug 1 15:19:43 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Aug 2016 17:19:43 +0200 Subject: [Freeipa-devel] [PATCH 0560] ipa-client-automount: don not initialize API during uninstall In-Reply-To: <86d3a8f3-fe5e-ee6e-d9c8-0bacc43ccc6b@redhat.com> References: <86d3a8f3-fe5e-ee6e-d9c8-0bacc43ccc6b@redhat.com> Message-ID: On 01.08.2016 14:28, Florence Blanc-Renaud wrote: > On 07/29/2016 04:56 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/6072 >> >> Patch attached. >> >> >> > Hi Martin, > > thanks for your patch. I could not reproduce the issue anymore with > ipa-client-automount --uninstall, thus looks good to me. > > Ack, > Flo. > Pushed to master: 2d4d1a9dc0ef2bbe86751768d6e6b009a52c0dc9 From pspacek at redhat.com Mon Aug 1 15:38:50 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 1 Aug 2016 17:38:50 +0200 Subject: [Freeipa-devel] [PATCH 0153] Fix ipa-replica-prepare's error message about missing local CA instanc Message-ID: <04a436fd-bc8b-e57b-d3dd-320b26fb0d68@redhat.com> Hello, Fix ipa-replica-prepare's error message about missing local CA instance ipa-replica-prepare must be run on a replica with CA or all the certs needs to be provided (for CA-less case). The old messages were utterly confusing because they mixed errors about missing certs and missing local CA instance into one text. https://fedorahosted.org/freeipa/ticket/6134 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0153-Fix-ipa-replica-prepare-s-error-message-about-missin.patch Type: text/x-patch Size: 2230 bytes Desc: not available URL: From pspacek at redhat.com Mon Aug 1 15:42:37 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 1 Aug 2016 17:42:37 +0200 Subject: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value In-Reply-To: <4f559de0-9e98-72d7-8844-0ae1e9ce2863@redhat.com> References: <7b729ec0-619f-17d4-bf2f-dceca268a444@redhat.com> <5467c214-4555-0d07-520f-9a280da2f7c9@redhat.com> <31ceaafa-4f54-7bcb-e7d1-1452d3eb5f30@redhat.com> <809195d1-83f7-bf47-df6b-ad2cc1851e50@redhat.com> <4f559de0-9e98-72d7-8844-0ae1e9ce2863@redhat.com> Message-ID: <4646992f-30e3-a8e5-5d84-97bf3d054d75@redhat.com> On 1.8.2016 08:27, Jan Cholasta wrote: > On 28.7.2016 16:55, Petr Spacek wrote: >> On 28.7.2016 16:44, Jan Cholasta wrote: >>> On 28.7.2016 16:37, Petr Spacek wrote: >>>> On 28.7.2016 16:35, Jan Cholasta wrote: >>>>> On 28.7.2016 16:20, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> install: Call hostnamectl set-hostname only if --hostname option is used >>>>>> >>>>>> This commit also splits hostname backup and configuration into two separate >>>>>> functions. This allows us to backup hostname without setting it at the >>>>>> same time. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6071 >>>>> >>>>> Note that you can set ca_host in cfg unconditionally, the value is only >>>>> valid >>>>> during install and is not written anywhere. >>>> >>>> I prefer not to set it so the code blows up when we attempt to touch >>>> variables >>>> we should reference in particular setups. I.e. Take this as a first step >>>> towards api.env without invalid values :-) >>> >>> OK. Use the proper condition then ("if setup_ca:"). >> >> Oh, I'm probably blind. Here is revised version. > > But you used "if not setup_ca:" rather than "if setup_ca:" :-) This patch set is cursed! Petr^2 Spacek > >> >> Petr^2 Spacek >> >>> >>>> >>>> (In my stash I have a patch which removes nonsense defaults from >>>> ipalib.constants. To be pushed when we a new git branch for 4.4...) >>>> >>>> Petr^2 Spacek >>>> >>>>>> server-install: Fix --hostname option to always override api.env values >>>>>> >>>>>> Attempts to compare local hostname with user-provided values are error >>>>>> prone as we found out in #5794. This patch removes comparison and makes >>>>>> the env values deterministic. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6071 >>>>>> >>>>>> >>>>>> Jan, this patch set should fix problems you have seen in containers. > > -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0151-3-server-install-Fix-hostname-option-to-always-overrid.patch Type: text/x-patch Size: 1838 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0152-3-install-Call-hostnamectl-set-hostname-only-if-hostna.patch Type: text/x-patch Size: 6031 bytes Desc: not available URL: From pvoborni at redhat.com Mon Aug 1 15:53:17 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 1 Aug 2016 17:53:17 +0200 Subject: [Freeipa-devel] [PATCH] webui: Fix coverity bugs In-Reply-To: <20160729132534.sdsdlda5c2gtvqj6@redhat.com> References: <17dedc13-dab5-4ae2-5a7b-d7921458a46f@redhat.com> <20160729132534.sdsdlda5c2gtvqj6@redhat.com> Message-ID: On 07/29/2016 03:25 PM, Alexander Bokovoy wrote: > On Fri, 29 Jul 2016, Pavel Vomacka wrote: >> Hello, >> >> please review attached patches which fixes errors from Coverity. >> >> -- >> Pavel^3 Vomacka >> > >> From 0391289b3f6844897e2a9f3ae549bd4c33233ffc Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Mon, 25 Jul 2016 10:36:47 +0200 >> Subject: [PATCH 01/13] Coverity - null pointer exception >> >> Variable 'option' can be null and there will be error of reading >> property of null. >> --- >> install/ui/src/freeipa/widget.js | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/install/ui/src/freeipa/widget.js >> b/install/ui/src/freeipa/widget.js >> index >> 9151ebac9438e9e674f81bfb1ccfe7a63872b1ae..cfdf5d4750951e4549c16a2b9b9c355f61e90c39 >> 100644 >> --- a/install/ui/src/freeipa/widget.js >> +++ b/install/ui/src/freeipa/widget.js >> @@ -2249,7 +2249,7 @@ IPA.option_widget_base = function(spec, that) { >> var child_values = []; >> var option = that.get_option(value); >> >> - if (option.widget) { >> + if (option && option.widget) { >> child_values = option.widget.save(); >> values.push.apply(values, child_values); >> } >> -- >> 2.5.5 >> > ACK ACK > >> From 6df8e608232e25daa9aefe4fccbdeca4dbaf1998 Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Mon, 25 Jul 2016 10:43:00 +0200 >> Subject: [PATCH 02/13] Coverity - null pointer exception >> >> Variable 'row' could be null in some cases. And set css to variable >> which is pointing to null >> causes error. Therefore there is new check. >> --- >> install/ui/src/freeipa/widget.js | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/install/ui/src/freeipa/widget.js >> b/install/ui/src/freeipa/widget.js >> index >> cfdf5d4750951e4549c16a2b9b9c355f61e90c39..5844436abf090f12d5a9d65efe7a1aaee14097e2 >> 100644 >> --- a/install/ui/src/freeipa/widget.js >> +++ b/install/ui/src/freeipa/widget.js >> @@ -5766,6 +5766,8 @@ exp.fluid_layout = IPA.fluid_layout = >> function(spec) { >> that.on_visible_change = function(event) { >> >> var row = that._get_row(event); >> + if (!row) return; >> + >> if (event.visible) { >> row.css('display', ''); >> } else { >> -- >> 2.5.5 >> > ACK ACK > > >> From 6f2ddc9e1c5323a640bdf744d2da00bfee7ab766 Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Mon, 25 Jul 2016 13:48:16 +0200 >> Subject: [PATCH 03/13] Coverity - not initialized variable >> >> The variable hasn't been initialized, now it is set to null by default. >> --- >> install/ui/src/freeipa/widget.js | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/install/ui/src/freeipa/widget.js >> b/install/ui/src/freeipa/widget.js >> index >> 5844436abf090f12d5a9d65efe7a1aaee14097e2..43804c5ea524ca741017d02f6e12ccf60d50b5df >> 100644 >> --- a/install/ui/src/freeipa/widget.js >> +++ b/install/ui/src/freeipa/widget.js >> @@ -1047,7 +1047,7 @@ IPA.multivalued_widget = function(spec) { >> >> that.child_spec = spec.child_spec; >> that.size = spec.size || 30; >> - that.undo_control; >> + that.undo_control = null; >> that.initialized = true; >> that.updating = false; >> >> -- >> 2.5.5 >> > ACK ACK > > >> From b9ddd32ec45aadae5a79e372c3e1b70990071e60 Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Mon, 25 Jul 2016 14:42:50 +0200 >> Subject: [PATCH 04/13] Coverity - identical code for different branches >> >> In both cases when the condition is true or false ut is set the same >> value. >> Changed to assign the value directly. >> --- >> install/ui/src/freeipa/topology_graph.js | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/install/ui/src/freeipa/topology_graph.js >> b/install/ui/src/freeipa/topology_graph.js >> index >> ce2ebeaff611987ae27f2655b5da80bdcd1b4f8a..712d38fbe67e87ffa773e0a3a1f8937e9595c9a6 >> 100644 >> --- a/install/ui/src/freeipa/topology_graph.js >> +++ b/install/ui/src/freeipa/topology_graph.js >> @@ -325,8 +325,8 @@ topology_graph.TopoGraph = declare([Evented], { >> off = dir ? -1 : 1, // determines shift direction of >> curve >> ns = 5, // shift on normal vector >> s = target_count > 1 ? 1 : 0, // shift from center? >> - spad = d.left ? 18 : 18, // source padding >> - tpad = d.right ? 18 : 18, // target padding >> + spad = d.left = 18, // source padding >> + tpad = d.right = 18, // target padding >> sourceX = d.source.x + (spad * ux) + off * nx * ns * s, >> sourceY = d.source.y + (spad * uy) + off * ny * ns * s, >> targetX = d.target.x - (tpad * ux) + off * nx * ns * s, >> -- >> 2.5.5 >> > ACK NACK following lines are not equivalent spad = d.left ? 18 : 18 spad = d.left = 18 same with tpad > >> From f1f2b55247d6c7f41f8053f372a47945c93fc8a4 Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Mon, 25 Jul 2016 14:52:15 +0200 >> Subject: [PATCH 05/13] Coverity - Accesing attribute of null >> >> There is a possibility that widget is null and then there could be an >> error. >> Therefore there is new check of widget variable. >> --- >> install/ui/src/freeipa/widgets/APIBrowserWidget.js | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> index >> 1a3726190d4a5d628a8f7c2b564c4c9f6e7cea1f..50c2989fcc126585787df61cdd19493632ed37b9 >> 100644 >> --- a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> +++ b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> @@ -252,7 +252,7 @@ widgets.APIBrowserWidget = declare([Stateful, >> Evented], { >> } >> >> // switch widget >> - if (!widget.el) widget.render(); >> + if (widget && !widget.el) widget.render(); >> if (this.current_details_w !== widget) { >> this.details_el.empty(); >> this.details_el.append(widget.el); >> -- >> 2.5.5 >> > ACK ACK > >> From 1476b5ed3ab5c4ec55f3ed20ad07a5b88cfd45f2 Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Mon, 25 Jul 2016 16:47:22 +0200 >> Subject: [PATCH 06/13] Coverity - removed dead code >> >> There cannot be string value because of previous checks. >> --- >> install/ui/src/freeipa/dns.js | 12 ++++-------- >> 1 file changed, 4 insertions(+), 8 deletions(-) >> >> diff --git a/install/ui/src/freeipa/dns.js >> b/install/ui/src/freeipa/dns.js >> index >> 2d424aeae8ef735d02426a0f08b6261ec2f04c19..822c0b3cedb3988563c0a1f83862f56e95eed21b >> 100644 >> --- a/install/ui/src/freeipa/dns.js >> +++ b/install/ui/src/freeipa/dns.js >> @@ -1509,14 +1509,10 @@ IPA.dns.record_prepare_editor_for_type = >> function(type, fields, widgets, update) >> >> //create editor widget >> var widget = {}; >> - if (typeof attribute === 'string') { >> - widget.name = attribute; >> - } else { >> - widget.name = attribute.name; >> - set_defined(attribute.$type, widget, '$type'); >> - set_defined(attribute.options, widget, 'options'); >> - copy_obj(widget, attribute.widget_opt); >> - } >> + widget.name = attribute.name; >> + set_defined(attribute.$type, widget, '$type'); >> + set_defined(attribute.options, widget, 'options'); >> + copy_obj(widget, attribute.widget_opt); >> section.widgets.push(widget); >> } >> }; >> -- >> 2.5.5 >> > ACK ACK > > >> From b1dd66f3b08889b51430d9176035366cb055324e Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Mon, 25 Jul 2016 17:44:56 +0200 >> Subject: [PATCH 07/13] Coverity - true branch can't be executed >> >> The 'data' variable is always false because of previous condition. >> Therefore there is direct assignment. >> --- >> install/ui/src/freeipa/rpc.js | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/install/ui/src/freeipa/rpc.js >> b/install/ui/src/freeipa/rpc.js >> index >> a185585f4176658e299e7e92434522c936cc36b4..88aaf6ede72ea69495c369dd74c657d0419a3605 >> 100644 >> --- a/install/ui/src/freeipa/rpc.js >> +++ b/install/ui/src/freeipa/rpc.js >> @@ -372,7 +372,7 @@ rpc.command = function(spec) { >> error_handler.call(this, xhr, text_status, /* >> error_thrown */ { >> name: text.get('@i18n:errors.http_error', 'HTTP >> Error')+' '+xhr.status, >> url: this.url, >> - message: data ? xhr.statusText : >> text.get('@i18n:errors.no_response', 'No response') >> + message: text.get('@i18n:errors.no_response', 'No >> response') >> }); >> >> } else if (IPA.version && data.version && IPA.version !== >> data.version) { >> -- >> 2.5.5 >> > ACK ACK - patch fixes the issue. But I wonder if it should be rather: message: xhr ? xhr.statusText : text.get('@i18n:errors.no_response', 'No response') don't remember. > > >> From 463f24936469d87890b666dfd7edabbe90541491 Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Mon, 25 Jul 2016 17:49:50 +0200 >> Subject: [PATCH 08/13] Coverity - true branch can't be executed >> >> The 'result' variable is always false because of previous condition. >> Therefore there is direct assignment. >> --- >> install/ui/src/freeipa/rpc.js | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/install/ui/src/freeipa/rpc.js >> b/install/ui/src/freeipa/rpc.js >> index >> 88aaf6ede72ea69495c369dd74c657d0419a3605..30a5366787974b2d127114f7683d0589ed332f5a >> 100644 >> --- a/install/ui/src/freeipa/rpc.js >> +++ b/install/ui/src/freeipa/rpc.js >> @@ -628,7 +628,7 @@ rpc.batch_command = function(spec) { >> >> if (!result) { >> name = text.get('@i18n:errors.internal_error', >> 'Internal Error')+' '+xhr.status; >> - message = result ? xhr.statusText : >> text.get('@i18n:errors.internal_error', 'Internal Error'); >> + message = text.get('@i18n:errors.internal_error', >> 'Internal Error'); >> >> that.errors.add(command, name, message, text_status); >> >> -- >> 2.5.5 >> > ACK same as previous > >> From c0ba1c141b6191e2a7ef33bc9eaaad5c970f9d0e Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Mon, 25 Jul 2016 18:25:36 +0200 >> Subject: [PATCH 09/13] Coverity - null pointer dereference >> >> The 'obj' variable could be null, so there could be error when it is >> used. >> A new check that 'obj' is not false is added. >> --- >> install/ui/src/freeipa/widgets/browser_widgets.js | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/install/ui/src/freeipa/widgets/browser_widgets.js >> b/install/ui/src/freeipa/widgets/browser_widgets.js >> index >> 57ad2bd984ea35f03b302b59fc1d014def162bd8..91bb850a638fd6f16f207b1111d126fbb4fe2dd8 >> 100644 >> --- a/install/ui/src/freeipa/widgets/browser_widgets.js >> +++ b/install/ui/src/freeipa/widgets/browser_widgets.js >> @@ -427,11 +427,11 @@ widgets.browser_widgets.CommandDetailWidget = >> declare([base], { >> if (i>0) { >> out_params_cnt.append(', '); >> } >> - if (!param) { >> - out_params_cnt.append(param_name); >> - } else { >> + if (param && obj) { >> var link = this.render_param_link(obj.name, >> param_name); >> out_params_cnt.append(link); >> + } else { >> + out_params_cnt.append(param_name); >> } >> } >> out_params_cnt.appendTo(this.el); >> -- >> 2.5.5 >> > ACK ACK > >> From a9f7ecf5833db379fe9731184aa4f7aef8845995 Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Tue, 26 Jul 2016 09:48:32 +0200 >> Subject: [PATCH 10/13] Coverity - iterating over variable which could >> be null >> >> Change condition to check also variable which could be null. >> --- >> install/ui/src/freeipa/widgets/APIBrowserWidget.js | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> index >> 50c2989fcc126585787df61cdd19493632ed37b9..18773536d3587cdeb9e5fecedcc5e42c05bfe120 >> 100644 >> --- a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> +++ b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> @@ -135,7 +135,7 @@ widgets.APIBrowserWidget = declare([Stateful, >> Evented], { >> groups = this._get_params(parts[0]); >> } >> >> - if (filter) { >> + if (filter && groups) { >> filter = filter.toLowerCase(); >> var new_groups = []; >> for (var i=0,l=groups.length; i> @@ -153,10 +153,10 @@ widgets.APIBrowserWidget = declare([Stateful, >> Evented], { >> new_groups.push(groups[i]); >> } >> } >> - return new_groups; >> - } else { >> - return groups; >> + groups = new_groups; >> } >> + >> + return groups; >> }, >> >> /** >> -- >> 2.5.5 >> > ACK ACK > > >> From 3d63ca1d5cb7a7b84cf20c26d4b1ea5b657c44c4 Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Tue, 26 Jul 2016 12:03:28 +0200 >> Subject: [PATCH 11/13] Coverity - opens dialog which might not be created >> >> Check whether dialog object is created before opening it. >> --- >> install/ui/src/freeipa/search.js | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/install/ui/src/freeipa/search.js >> b/install/ui/src/freeipa/search.js >> index >> 25f21e70db170daf0d45a6862ee9adb528ad03bc..fee1bc7523d6afdb3e2b23db2833a415febb85ec >> 100644 >> --- a/install/ui/src/freeipa/search.js >> +++ b/install/ui/src/freeipa/search.js >> @@ -221,7 +221,7 @@ IPA.search_facet = function(spec, no_init) { >> that.show_remove_dialog = function() { >> >> var dialog = that.create_remove_dialog(); >> - dialog.open(); >> + if (dialog) dialog.open(); >> }; >> >> that.find = function() { >> -- >> 2.5.5 >> > ACK ACK but question is whether we should laso log to console that dialog is not defined because it just hides an issue which may be harder to debug. > >> From 7819293fc546de31cc5eea246242742af3be094e Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Tue, 26 Jul 2016 13:07:30 +0200 >> Subject: [PATCH 12/13] Coverity - accessing attribute of variable >> which can >> point to null >> >> Added check whether variable is pointing to null or not. >> --- >> install/ui/src/freeipa/widget.js | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/install/ui/src/freeipa/widget.js >> b/install/ui/src/freeipa/widget.js >> index >> 43804c5ea524ca741017d02f6e12ccf60d50b5df..1f61ce7341b1b8e13d4df5acea1f8901a63a290a >> 100644 >> --- a/install/ui/src/freeipa/widget.js >> +++ b/install/ui/src/freeipa/widget.js >> @@ -4938,7 +4938,7 @@ IPA.combobox_widget = function(spec) { >> var value = that.list.val(); >> var option = $('option[value="'+value+'"]', that.list); >> var next = option.next(); >> - if (!next.length) return; >> + if (!next || !next.length) return; >> that.select(next.val()); >> }; >> >> @@ -4946,7 +4946,7 @@ IPA.combobox_widget = function(spec) { >> var value = that.list.val(); >> var option = $('option[value="'+value+'"]', that.list); >> var prev = option.prev(); >> - if (!prev.length) return; >> + if (!prev || !prev.length) return; >> that.select(prev.val()); >> }; >> >> -- >> 2.5.5 >> > ACK ACK, but IMO the situation cannot happen. .next() and .prev() should not return null ever. > >> From 3ba5110fa8b2255b83fa3e7a4135ec33b85a7fd8 Mon Sep 17 00:00:00 2001 >> From: Pavel Vomacka >> Date: Fri, 29 Jul 2016 10:13:21 +0200 >> Subject: [PATCH 13/13] Coverity - null pointer dereference >> >> Add check which protect from calling method of null. >> --- >> install/ui/src/freeipa/widgets/APIBrowserWidget.js | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> index >> 18773536d3587cdeb9e5fecedcc5e42c05bfe120..2164df2f5ffa00edf9ac41fd4cf6254f6d4eb9a3 >> 100644 >> --- a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> +++ b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >> @@ -264,7 +264,7 @@ widgets.APIBrowserWidget = declare([Stateful, >> Evented], { >> this.list_w.select(item); >> >> // set item >> - widget.set('item', item); >> + if (widget) widget.set('item', item); >> this.set('current', { >> item: item, >> type: type, >> -- >> 2.5.5 >> > ACK > Does it fix the issue? There is a line before this one which also uses `widget` if (!widget.el) widget.render(); maybe we miss `return;` in: } else { IPA.notify("Invalid type", 'error'); this.show_default(); } -- Petr Vobornik From mbasti at redhat.com Mon Aug 1 16:31:49 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Aug 2016 18:31:49 +0200 Subject: [Freeipa-devel] [PATCH] 0001 six.u function instead of the decode In-Reply-To: References: <3afeae65-e827-70d2-948d-89eef71bbcd3@redhat.com> <8e4e551f-3446-9d33-de19-1dc4996ff697@redhat.com> Message-ID: <700f2038-908a-8d21-b2b6-d25079c74fa4@redhat.com> On 28.07.2016 18:29, Ariel Barria wrote: > 2016-07-28 7:10 GMT-05:00 Petr Spacek : >> On 27.7.2016 18:26, Ariel Barria wrote: >>> 2016-07-26 9:39 GMT-05:00 Petr Spacek : >>>> On 26.7.2016 16:28, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 26.7.2016 16:09, Martin Basti wrote: >>>>>> >>>>>> On 22.07.2016 00:14, Ariel Barria wrote: >>>>>>> Hello everyone. >>>>>>> >>>>>>> I send patch for review. >>>>> NACK, six.u() is supposed to be used on string literals *only* [1]. >>>>> >>>>> A proper fix would be something like: >>>>> >>>>> value = self.to_text() >>>>> if not isinstance(value, unicode): >>>>> value = value.decode('ascii') >>>>> return value >>> thanks for the guidance and comments >>> >>>> Most importantly, we should fix/provide this method in python-dns and inherit >>>> this method from there. >>> Well, I made a pr, but apparently travis ci test failed with other >>> versions of python, so it is possible that they do not approve, I will >>> be performing other tests to see what the downside. >>> >>> https://github.com/rthalley/dnspython/pull/195 >> Looking at the PR, there are functions >> dns.name.to_text() >> dns.name.to_unicode() >> >> What is missing in them? >> >> Petr^2 Spacek >> >> >>>>>> I will look on this, for some reason we received your e-mail just today >>>>>> (2016-07-26) >>> welcome. >>> it was my mistake, I sent the patch to the list before being signed to the list >>> >>>>> Honza >>>>> >>>>> [1] >> -- >> Petr^2 Spacek > Hi. > I send the requested changes > thanks for review. > > According the https://github.com/rthalley/dnspython/blob/master/dns/name.py#L375 New dnspython always return binary strings, so we should always decode it, because IPA internals need punycoded domain in unicode format IMO this is broken in current dnspython released in Fedora. There are plenty of py3 bugs, we have to provide newer dnspython package to fedora, so this should not be fixed on IPA side. regards Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Aug 1 16:56:26 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 1 Aug 2016 18:56:26 +0200 Subject: [Freeipa-devel] [PATCH] 0001 six.u function instead of the decode In-Reply-To: <700f2038-908a-8d21-b2b6-d25079c74fa4@redhat.com> References: <3afeae65-e827-70d2-948d-89eef71bbcd3@redhat.com> <8e4e551f-3446-9d33-de19-1dc4996ff697@redhat.com> <700f2038-908a-8d21-b2b6-d25079c74fa4@redhat.com> Message-ID: <7c4f0886-4f73-f94c-4c20-13a35edde30c@redhat.com> On 1.8.2016 18:31, Martin Basti wrote: > > > On 28.07.2016 18:29, Ariel Barria wrote: >> 2016-07-28 7:10 GMT-05:00 Petr Spacek : >>> On 27.7.2016 18:26, Ariel Barria wrote: >>>> 2016-07-26 9:39 GMT-05:00 Petr Spacek : >>>>> On 26.7.2016 16:28, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 26.7.2016 16:09, Martin Basti wrote: >>>>>>> >>>>>>> On 22.07.2016 00:14, Ariel Barria wrote: >>>>>>>> Hello everyone. >>>>>>>> >>>>>>>> I send patch for review. >>>>>> NACK, six.u() is supposed to be used on string literals *only* [1]. >>>>>> >>>>>> A proper fix would be something like: >>>>>> >>>>>> value = self.to_text() >>>>>> if not isinstance(value, unicode): >>>>>> value = value.decode('ascii') >>>>>> return value >>>> thanks for the guidance and comments >>>> >>>>> Most importantly, we should fix/provide this method in python-dns and >>>>> inherit >>>>> this method from there. >>>> Well, I made a pr, but apparently travis ci test failed with other >>>> versions of python, so it is possible that they do not approve, I will >>>> be performing other tests to see what the downside. >>>> >>>> https://github.com/rthalley/dnspython/pull/195 >>> Looking at the PR, there are functions >>> dns.name.to_text() >>> dns.name.to_unicode() >>> >>> What is missing in them? >>> >>> Petr^2 Spacek >>> >>> >>>>>>> I will look on this, for some reason we received your e-mail just today >>>>>>> (2016-07-26) >>>> welcome. >>>> it was my mistake, I sent the patch to the list before being signed to the >>>> list >>>> >>>>>> Honza >>>>>> >>>>>> [1] >>> -- >>> Petr^2 Spacek >> Hi. >> I send the requested changes >> thanks for review. >> >> > > According the https://github.com/rthalley/dnspython/blob/master/dns/name.py#L375 > > New dnspython always return binary strings, so we should always decode it, > because IPA internals need punycoded domain in unicode format > > IMO this is broken in current dnspython released in Fedora. There are plenty > of py3 bugs, we have to provide newer dnspython package to fedora, so this > should not be fixed on IPA side. I'm fine with rebasing python-dns in Fedora when we find a version which works better. Just tell me what version it is :-) -- Petr^2 Spacek From ofayans at redhat.com Mon Aug 1 20:46:23 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 1 Aug 2016 22:46:23 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: <5772622C.9000205@redhat.com> References: <57723947.2090508@redhat.com> <5772622C.9000205@redhat.com> Message-ID: <579FB51F.6030808@redhat.com> The test was redesigned so that it actually tests against an AD user. cleanly applies, passes lint and passes https://paste.fedoraproject.org/399504/00843641/ On 06/28/2016 01:40 PM, Oleg Fayans wrote: > Patch-0050 rebased against latest upstream branch > > On 06/28/2016 10:45 AM, Oleg Fayans wrote: >> Passing test output: >> >> https://paste.fedoraproject.org/385774/71035231/ >> >> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ftweedal at redhat.com Tue Aug 2 03:57:46 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 2 Aug 2016 13:57:46 +1000 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> Message-ID: <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> On Fri, Jul 29, 2016 at 11:13:16AM -0400, Ben Lipton wrote: > > On 07/29/2016 09:39 AM, Petr Spacek wrote: > > On 27.7.2016 19:06, Ben Lipton wrote: > > > Hi all, > > > > > > I think the automatic CSR generation feature > > > (https://fedorahosted.org/freeipa/ticket/4899, > > > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation) is > > > stable enough to review now. The following are summaries of the attached patches: > > > 0004: LDAP schema changes for the new feature > > > 0005: Basic API for new objects and CSR generation > > > 0006: Update install automation to create some default mapping rules > > > 0007: Implement the lookups and text processing that generates the CSR config > > > 0008 and 0009: Implement some actual transformation rules so that the feature > > > is usable > > > 0010: Add a new cert profile for user certs, with mappings > > > 0011: Implement import/export of cert profiles with mappings > > > 0012: Tests for profile import/export > > > > > > Generally speaking, later patches depend on earlier ones, but I don't > > > anticipate any problems from committing earlier patches without later ones. > > > > > > If you prefer, you can also comment on the pull request version: > > > https://github.com/LiptonB/freeipa/pull/4. Note that I may force push on this > > > branch. > > > > > > Allocation of OIDs for schema change also needs review: > > > https://code.engineering.redhat.com/gerrit/#/c/80061/ > > > > > > Known issues: > > > - When the requested principal does not have some of the requested data, > > > produces funny-looking configs with extra commas, empty sections, etc. They > > > are still accepted by my copies of openssl and certutil, but they look ugly. > > > - The new objects don't have any ACIs, so for the moment only admin can run > > > the new commands. > > > - Does not yet have support for prompting user for field values, so currently > > > all data must come from the database. > > > - All processing happens on the server side. As discussed in a previous > > > thread, it would be desirable to break this out into a library so it could be > > > used client-side. > > > > > > Very excited to hear your thoughts! > > Hi Ben, > > > > I wanted to give it a try from user's point of view first, before diving into > > implementation details. Here are some observations: > > Thanks for giving it a try! This is great feedback. > > > > 0. Design pages are using term "helper" and it is used even as option in the > > example with smartcards. Please fix either design page or the code so they are > > consistent. > Good point. In a previous discussion, Alexander remarked that --helper > sounded too low-level, but I find that --use sounds very generic and > --format doesn't make a lot of sense for ipa cert-request, which never > actually gives you the config that's generated. So if they're all going to > be the same word, which is probably a good idea, I might be leaning towards > --helper, but I'm interested to hear opinions on this. > > > > 1. The "ipa cert-request" command is missing options --autofill and --use (aka > > helper aka format :-) which are mentioned in the design pages. > Yeah, I haven't managed to implement much of the UI niceness suggested by > the design page. I probably should have mentioned that in the email - all > that I expect to be working at this point is 'ipa cert-get-requestdata' and > CRUD for the mapping rules/profiles themselves. > > > > 2. "ipa cert_get_requestdata" command passes even without --profile-id and > > generates empty config. I think that this is not expected :-) > > More expected than you might think :) I'm guessing what's happening is that > you're passing a user principal and it's defaulting to the caIPAserviceCert > profile, then failing to fill out any of the fields because the data it > needs is not there. I agree this isn't great. I was planning to address this > by having it throw an error if it can't generate at least the subject of the > request, and maybe suggest using a different profile. > > I chose to have it default to caIPAserviceCert because that's what ipa > cert-request does, but maybe that's not as predictable as I thought. > In general use I think that 'caIPAserviceCert' is unlikely to be used a majory of the time, and it is a new command so there are no compatibility issues; therefore why not make the profile option mandatory? > > > > 3. "ipa cert_get_requestdata --format=openssl" prints the text to stdout > > including label "Configuration file contents:". This is hard to use because > > simple redirection like "ipa cert_get_requestdata --format=openssl > config" > > will not give you valid OpenSSL config file - it needs hand-editing. > > > > It would be good to add --out parameter you envisioned in the design page. > > Please ask jcholast for proper name and semantics :-) With --out option the > > command can be used to generate valid config (or script if certutil was selected). > Agreed. Another example of the UI not being quite right yet. I've been > unsure how to handle this, because of certutil taking a command line and > openssl a config file. It actually gets even more complicated because, as > you point out in the next item, openssl also needs a command in addition to > the config file. I'm interested in thinking about how to handle this cleanly > from a user perspective. Generating a script, or providing the command lines > as hints, might be ways to get around these concerns. > > 4. "ipa cert_get_requestdata --format=openssl" could print hint what OpenSSL > > command should be executed on the generated config file. For testing I've used > > command "openssl req -new -out csr -text -config config" (stolen and modified > > from smart card example). Also, as a second hint, it could print the IPA > > command which needs to be used to sign the CSR generated by the helper. > Also agreed, the framework should be able to generate and (for purposes of > 'ipa cert-request --autofill') even execute the command required to make the > CSR. > > > > > 5. My naive attempt to get userCert for admin failed: > > $ ipa cert_get_requestdata --format=openssl --principal=admin > > --profile-id=userCert > usercert.conf > > # remove the trailing label > > $ openssl req -new -out csr -text -config usercert.conf > > $ ipa cert-request --principal=admin --profile-id=userCert usercert.csr > > ipa: ERROR: invalid 'csr': No Common Name was found in subject of request. > > > > I'm attaching files generated by the commands above. I did not modify anything > > in the templates or profiles, just tried to use the new profile added by > > freeipa-blipton-0010-Add-a-new-cert-profile-for-users.patch . > > Hah! This is what I get for thinking I know what the output has to look > like, and not testing all the way through to requesting the cert. I'll > change the profile to generate a subject with CN= instead of UID=. Updated > patch is attached. Unfortunately these rules are only updated at > ipa-server-install time, so if you'd like to fix it without reinstalling: > (Tangential commentary...) Yeah, currently cert-request demands the CN. There is a design to relax the requirement to handle empty subject names (look at SAN only). IMO it would make sense to accept other "obvious" mappings in Subject DN like accepting UID instead of CN for user subjects, but that would be a separate RFE. Noone has actually asked for it yet :) Cheers, Fraser > ipa certtransformationrule-mod dataUsernameCN dataUsernameCertutil > --template 'CN={{ipa.datafield(subject.uid.0)|quote}},{{ipa.datafield(config.ipacertificatesubjectbase.0)|quote}}' > ipa certtransformationrule-mod dataUsernameCN dataUsernameOpenssl --template > '{{ipa.datafield(config.ipacertificatesubjectbase.0)}} > CN={{ipa.datafield(subject.uid.0)}}' > Yes, that must be an actual linebreak between the subjectbase and the CN in > the openssl one. I know :-/ > > > > > Hopefully I will get to other things soon (but not this week). > > > > > > Anyway, all this seems like (expected) initial problems. In general the first > > touch with user interface seems reasonable and needs only small improvements. > > > > Good work! > > From slaznick at redhat.com Tue Aug 2 07:11:46 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 2 Aug 2016 09:11:46 +0200 Subject: [Freeipa-devel] [PATCH 0059] Fix to ipa-cacert-manage man and help differences In-Reply-To: <182017ec-6015-c99a-8e96-cbeefaefa970@redhat.com> References: <33e33813-1aeb-3d50-e05c-cadc3cb8e4bb@redhat.com> <182017ec-6015-c99a-8e96-cbeefaefa970@redhat.com> Message-ID: On 07/19/2016 10:25 AM, Florence Blanc-Renaud wrote: > On 07/15/2016 02:09 PM, Stanislav Laznicka wrote: >> https://fedorahosted.org/freeipa/ticket/6013 >> >> >> > Hi Stanislav, > > thanks for your patch. As CERTFILE is added in the arguments for > install, I would suggest to mention it in the command description. For > instance: > > install > - Install a CA certificate > This command can be used to install the certificate contained in > CERTFILE as a new CA certificate to IPA. > > Flo. > Hi, Thanks for the notice, I agree that it'd be better to be more verbose about the CERTFILE argument. Please see the modified patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0059-2-Improvements-for-the-ipa-cacert-manage-man-and-help.patch Type: text/x-patch Size: 4050 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 2 10:31:58 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 2 Aug 2016 12:31:58 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: <579FB51F.6030808@redhat.com> References: <57723947.2090508@redhat.com> <5772622C.9000205@redhat.com> <579FB51F.6030808@redhat.com> Message-ID: <98a90ec8-fa79-dd36-57dc-053204c29506@redhat.com> On 01.08.2016 22:46, Oleg Fayans wrote: > The test was redesigned so that it actually tests against an AD user. > cleanly applies, passes lint and passes > > https://paste.fedoraproject.org/399504/00843641/ Okay Did you forget to send patches? Martin^2 > > > On 06/28/2016 01:40 PM, Oleg Fayans wrote: >> Patch-0050 rebased against latest upstream branch >> >> On 06/28/2016 10:45 AM, Oleg Fayans wrote: >>> Passing test output: >>> >>> https://paste.fedoraproject.org/385774/71035231/ >>> >>> >>> >> >> >> > From slaznick at redhat.com Tue Aug 2 11:08:08 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 2 Aug 2016 13:08:08 +0200 Subject: [Freeipa-devel] [PATCH 0048] Remove sys.exit() from installer modules In-Reply-To: <92bbb69d-cba7-a820-8254-00b684cdbada@redhat.com> References: <91e234f8-554f-7efd-a399-d51db521a2fe@redhat.com> <9e9d6098-cbe2-3455-47c0-a21d1aea8ae5@redhat.com> <28420a22-04ad-b04c-4c25-bd9a71f9051f@redhat.com> <9171d38e-da4f-0693-1f53-767dc4dfe219@redhat.com> <5763ABED.9010102@redhat.com> <5763D892.20605@redhat.com> <3b048d9c-03c8-1675-0a3f-20e4b8e293c2@redhat.com> <92bbb69d-cba7-a820-8254-00b684cdbada@redhat.com> Message-ID: On 07/28/2016 10:57 AM, Martin Basti wrote: > On 17.06.2016 13:56, Stanislav Laznicka wrote: >> On 06/17/2016 01:01 PM, Petr Vobornik wrote: >>> On 17.6.2016 12:12, Stanislav Laznicka wrote: >>>> On 06/17/2016 09:51 AM, Petr Vobornik wrote: >>>>> On 17.6.2016 09:24, Stanislav Laznicka wrote: >>>>>> On 06/17/2016 08:48 AM, Petr Spacek wrote: >>>>>>> On 17.6.2016 08:43, Stanislav Laznicka wrote: >>>>>>>> On 06/17/2016 07:45 AM, Petr Spacek wrote: >>>>>>>>> On 16.6.2016 17:33, Stanislav Laznicka wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> This patch removes most sys.exits() from installer modules and >>>>>>>>>> scripts and >>>>>>>>>> replaces them with ScriptError. I only left sys.exits at places >>>>>>>>>> where the user >>>>>>>>>> decides yes/no on continuation of the script. >>>>>>>>> I wonder if yes/no should be replaced with KeyboardInterrupt >>>>>>>>> or some >>>>>>>>> other >>>>>>>>> exception, too... >>>>>>>>> >>>>>>>> I'm not sure, it seems more clear to just really exit if the user >>>>>>>> desires it >>>>>>>> and it's what we say we'll do (with possible cleanup >>>>>>>> beforehand). Do >>>>>>>> you think >>>>>>>> we could benefit somehow by raising an exception here? >>>>>>> I'm just thinking out loud. >>>>>>> >>>>>>> It seemed to me that it is easier to share cleanup on one except >>>>>>> block >>>>>>> instead >>>>>>> of having if (interrupt): cleanup; if (interrupt2): same_cleanup; >>>>>>> >>>>>>> etc. >>>>>>> >>>>>>> Again, just wondering out loud. >>>>>>> >>>>>> If the cleanup is the same, or similar it might be more >>>>>> beneficial to >>>>>> have it in a function where you could pass what was set up >>>>>> already and >>>>>> therefore needs cleanup. But that's just an opinion coming from >>>>>> thinking >>>>>> out loud as well. I went through the code to see if there's much >>>>>> cleanup >>>>>> after these user actions and it seems that usually there's >>>>>> nothing much >>>>>> if anything. However, thinking in advance may save us much >>>>>> trouble in >>>>>> the future, of course. >>>>>> >>>>> Btw the original scope of the ticket is to replace sys.exit calls >>>>> ONLY >>>>> in installer modules. Please don't waste time with debugging other >>>>> use >>>>> cases before 4.4 is out. >>>>> >>>> I might have gotten carried away a bit. Would you suggest keeping the >>>> sys.exits replaced only in ipaserver/install/server/replicainstall.py, >>>> ipaserver/install/server/install.py modules which are the installer >>>> modules managed by AdminTool? I considered the modules in >>>> ipaserver/install/ to also be installer modules as they are heavily >>>> used >>>> during installation and the sys.exits there mainly occur in functions >>>> called from install()/install_check() methods. The *-install scripts >>>> were perhaps really obviously over the scope. >>> Yes, modules: >>> ipaserver/install/bindinstance.py | 2 +- >>> ipaserver/install/ca.py | 19 +++--- >>> ipaserver/install/cainstance.py | 5 +- >>> ipaserver/install/dns.py | 5 +- >>> ipaserver/install/dsinstance.py | 3 +- >>> ipaserver/install/installutils.py | 16 +++--- >>> ipaserver/install/ipa_ldap_updater.py | 2 +- >>> ipaserver/install/krainstance.py | 3 +- >>> ipaserver/install/replication.py | 10 ++-- >>> ipaserver/install/server/install.py | 64 +++++++++++---------- >>> ipaserver/install/server/replicainstall.py | 92 >>> >>> not modules: >>> install/tools/ipa-adtrust-install | 17 +++--- >>> install/tools/ipa-ca-install | 23 ++++---- >>> install/tools/ipa-compat-manage | 11 ++-- >>> install/tools/ipa-dns-install | 3 +- >>> >>>> I'll keep the sys.exit replaces that won't make it here on the >>>> side, we >>>> may want to do them later. >>> I'm a bit worried that the patch might change some behavior. Maybe I'm >>> wrong. >>> >> Attached is the patch with correct modules with sys.exits replaced. >> >> I double-checked the changes and I believe the behavior shouldn't >> really change. >> >> >> > > Hello, > > suprisingly, patch needs rebase :) > > 1) > Is the script error the right Exception? I chose ScriptError because it's able to change the return value of the script, which is necessary sometimes. RuntimeError, which may seem more suitable, would not be able to do that. However, I am open for ideas on which exception type to use. > > 2) > Can you use rather raise Exception(), instead of raise Exception > Sure, please see the modified attached patch. > 3) > I really hate to print errors to STDOUT from modules and then just > call exit(1) (duplicated evil), could you replace print('xxx') with > raise AnException('xxx') Did that, only kept those prints printing directly to stderr. Not sure if those should be changed as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0048-3-Remove-sys.exit-from-install-modules-and-scripts.patch Type: text/x-patch Size: 43236 bytes Desc: not available URL: From ofayans at redhat.com Tue Aug 2 11:11:32 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 2 Aug 2016 13:11:32 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: <98a90ec8-fa79-dd36-57dc-053204c29506@redhat.com> References: <57723947.2090508@redhat.com> <5772622C.9000205@redhat.com> <579FB51F.6030808@redhat.com> <98a90ec8-fa79-dd36-57dc-053204c29506@redhat.com> Message-ID: <57A07FE4.8000904@redhat.com> Hi Martin, I did! Thank you! On 08/02/2016 12:31 PM, Martin Basti wrote: > > > On 01.08.2016 22:46, Oleg Fayans wrote: >> The test was redesigned so that it actually tests against an AD user. >> cleanly applies, passes lint and passes >> >> https://paste.fedoraproject.org/399504/00843641/ > > Okay > > Did you forget to send patches? > > Martin^2 >> >> >> On 06/28/2016 01:40 PM, Oleg Fayans wrote: >>> Patch-0050 rebased against latest upstream branch >>> >>> On 06/28/2016 10:45 AM, Oleg Fayans wrote: >>>> Passing test output: >>>> >>>> https://paste.fedoraproject.org/385774/71035231/ >>>> >>>> >>>> >>> >>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0049.1-Added-interface-to-certutil.patch Type: text/x-patch Size: 1137 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0050.2-Automated-test-for-certs-in-idoverrides-feature.patch Type: text/x-patch Size: 6469 bytes Desc: not available URL: From flo at redhat.com Tue Aug 2 11:22:10 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 2 Aug 2016 13:22:10 +0200 Subject: [Freeipa-devel] [PATCH] 0013 Fix ipa hbactest output Message-ID: Hi, please find attached a patch related to 'ipa hbactest' producing a Traceback. https://fedorahosted.org/freeipa/ticket/6157 Flo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-0013-Fix-ipa-hbactest-output.patch Type: text/x-patch Size: 1393 bytes Desc: not available URL: From slaznick at redhat.com Tue Aug 2 11:47:17 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 2 Aug 2016 13:47:17 +0200 Subject: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument In-Reply-To: <7a64f453-df5a-0691-746c-1b04c7171f8a@redhat.com> References: <7a64f453-df5a-0691-746c-1b04c7171f8a@redhat.com> Message-ID: <47ac8912-1caf-bdd8-bb32-fdb29dffffb8@redhat.com> On 07/19/2016 09:20 AM, Jan Cholasta wrote: > Hi, > > On 14.7.2016 14:36, Stanislav Laznicka wrote: >> Hello, >> >> This patch fixes https://fedorahosted.org/freeipa/ticket/5640. >> >> With not so much experience with the framework, it raises question in my >> head whether ipaldap.get_entries is used properly throughout the system >> - does it always assume that it gets ALL the requested entries or just a >> few of those as configured by the 'ipaSearchRecordsLimit' attribute of >> ipaConfig.etc which it actually gets? > > That depends. If you call get_entries() on the ldap2 plugin (which is > usually the case in the framework), then ipaSearchRecordsLimit is > used. If you call it on some arbitrary LDAPClient instance, the > hardcoded default (= unlimited) is used. > >> >> One spot that I know the get_entries method was definitely not used >> properly before this patch is in the >> baseldap.LDAPObject.get_memberindirect() method: >> >> 692 result = self.backend.get_entries( >> 693 self.api.env.basedn, >> 694 filter=filter, >> 695 attrs_list=['member'], >> 696 size_limit=-1, # paged search will get everything >> anyway >> 697 paged_search=True) >> >> which to me seems kind of important if the environment size_limit is not >> set properly :) The patch does not fix the non-propagation of the >> paged_search, though. > > Why do you think size_limit is not used properly here? AFAIU it is desired that the search is unlimited. However, due to the fact that neither size_limit nor paged_search are passed from ldap2.get_entries() to ldap2.find_entries() (methods inherited from LDAPClient), only the number of records specified by ipaSearchRecordsLimit is returned. That could eventually cause problems should ipaSearchRecordsLimit be set to a low value as in the ticket. > > Anyway, this ticket is not really easily fixable without more profound > changes. Often, multiple LDAP searches are done during command > execution. What do you do with the size limit then? Do you pass the > same size limit to all the searches? Do you subtract the result size > from the size limit after each search? Do you do something else with > it? ... The answer is that it depends on the purpose of each > individual LDAP search (like in get_memberindirect() above, we have to > do unlimited search, otherwise the resulting entry would be > incomplete), and fixing this accross the whole framework is a > non-trivial task. > I do realize that the proposed fix for the permission plugin is not perfect, it would probably be better to subtract the number of currently loaded records from the sizelimit, although in the end the number of returned values will not be higher than the given size_limit. However, it seems reasonable that if get_entries is passed a size limit, it should apply it over current ipaSearchRecordsLimit rather than ignoring it. Then, any use of get_entries could be fixed accordingly if someone sees fit. From ldoudova at redhat.com Tue Aug 2 12:50:51 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 2 Aug 2016 14:50:51 +0200 Subject: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate In-Reply-To: References: <1004948019.9643194.1469705403940.JavaMail.zimbra@redhat.com> <11d0579b-2ca2-af88-ed97-2efa477290c0@redhat.com> <529785673.9646711.1469705707399.JavaMail.zimbra@redhat.com> Message-ID: On 07/29/2016 11:43 AM, Lenka Doudova wrote: > > > > On 07/29/2016 11:41 AM, Lenka Doudova wrote: >> >> On 07/28/2016 01:35 PM, Peter Lacko wrote: >>> Hops, fixed. >>> >>> Peter >>> >>> >>> ----- Original Message ----- >>> From: "Lenka Doudova" >>> To:freeipa-devel at redhat.com >>> Sent: Thursday, July 28, 2016 1:32:25 PM >>> Subject: Re: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate >>> >>> Hi, >>> >>> I cannot find any attached patch :) >>> >>> Lenka >>> >>> >>> On 07/28/2016 01:30 PM, Peter Lacko wrote: >>>> Attached you can find a patch adding test for URIs in generated certificate >>>> ipatests/test_xmlrpc/test_cert_plugin.py >>>> Since I'm leaving Red Hat in end of July, I won't be able to modify this patch anymore. >>>> >>>> Regards, >>>> >>>> Peter >>>> >>> >>> >> Hi, >> >> NACK. Code looks fine and works well on master branch, but patch does >> not apply on 4-3 and 4-2 branches. >> Peter left the company but claimed he can fix the patch if necessary, >> I'll communicate it with him or fix it myself. >> >> Lenka >> >> > Oh, and forgot this one - PEP8 error: > ./ipatests/test_xmlrpc/test_cert_plugin.py:191:80: E501 line too long > (105 > 79 characters) > > Lenka > > Hi, since Peter has quit already, I took it upon myself to do minor fix and rebase to the patch. 1) i removed pylint disable comments from the patch, as they were unnecessary (this also solved PEP8 error) 2) I rebased the patch to be applicable for ipa-4-3 branch. Original functionality of the patch remains unchanged. Both fixed patches attached. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-placko-0003-2-ipa43-Test-URIs-in-certificate.patch Type: text/x-patch Size: 4814 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-placko-0003-2-Test-URIs-in-certificate.patch Type: text/x-patch Size: 4767 bytes Desc: not available URL: From pvomacka at redhat.com Tue Aug 2 14:51:25 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 2 Aug 2016 16:51:25 +0200 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint Message-ID: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> Hello, please review attached patches which Split make lint to more targets and add jslint -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0098-Split-targets-in-Makefile.patch Type: text/x-patch Size: 1878 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0099-Add-jslint-to-make-lint-target.patch Type: text/x-patch Size: 1323 bytes Desc: not available URL: From abokovoy at redhat.com Tue Aug 2 14:57:38 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 2 Aug 2016 17:57:38 +0300 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <579F67F8.6020007@redhat.com> References: <579F67F8.6020007@redhat.com> Message-ID: <20160802145738.6bajhge2pms5ukb6@redhat.com> On Mon, 01 Aug 2016, Rob Crittenden wrote: >Tibor Dudlak wrote: >>Hi, >> >>I have added few lines to code to make optional login with personal >>certificate (or with smartcard) possible. Some ui changes has to be >>made. It is not cosher but it definitely work. >> >>Thank you, Tibor >> > >What about the Apache changes to require a certificate in >/ipa/session/login_x509? > >Does/will this only support a specially crafted certificate subject? > >How/where does the UI get a Kerberos ticket for the user? That's indeed a problem -- even with the PKINIT support in KDC that Simo is polishing up now, we don't have a way to obtain a ticket on behalf of the user because Apache would terminate the SSL negotiation and we wouldn't be able to use user's certificate to do PKINIT negotiation to obtain a ticket as a user and then continue running on its behalf. Neither we would get any Kerberos ticket from the client side. -- / Alexander Bokovoy From cheimes at redhat.com Tue Aug 2 15:02:26 2016 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 2 Aug 2016 17:02:26 +0200 Subject: [Freeipa-devel] [PATCH 33] Correct path to HTTPD's systemd service directory Message-ID: Ticket #5681 and commit 586fee293f42388510fa5436af19460bbe1fdec5 changed the location of the ipa.conf for Apache HTTPD. The variables SYSTEMD_SYSTEM_HTTPD_D_DIR and SYSTEMD_SYSTEM_HTTPD_IPA_CONF point to the wrong directory /etc/systemd/system/httpd.d/. The path is corrected to /etc/systemd/system/httpd.service.d/. https://fedorahosted.org/freeipa/ticket/6158 https://bugzilla.redhat.com/show_bug.cgi?id=1362537 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0033-Correct-path-to-HTTPD-s-systemd-service-directory.patch Type: text/x-patch Size: 1830 bytes Desc: not available URL: From rcritten at redhat.com Tue Aug 2 15:12:05 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 2 Aug 2016 11:12:05 -0400 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> Message-ID: <57A0B845.5000105@redhat.com> Pavel Vomacka wrote: > Hello, > > please review attached patches which Split make lint to more targets and > add jslint What's the driver to split the checks out into separate targets? You are moving the makeapi and makeaci from version-update to lint. They were in version-update for a reason: downstream builds do not call lint. Downstream may patch code. API cannot break. No ticket? rob From akasurde at redhat.com Tue Aug 2 15:12:25 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Tue, 2 Aug 2016 20:42:25 +0530 Subject: [Freeipa-devel] [PATCH 33] Correct path to HTTPD's systemd service directory In-Reply-To: References: Message-ID: <59eb2164-23c1-7431-788e-72f929b3adeb@redhat.com> On 08/02/2016 08:32 PM, Christian Heimes wrote: > Ticket #5681 and commit 586fee293f42388510fa5436af19460bbe1fdec5 changed > the location of the ipa.conf for Apache HTTPD. The variables > SYSTEMD_SYSTEM_HTTPD_D_DIR and SYSTEMD_SYSTEM_HTTPD_IPA_CONF point to > the wrong directory /etc/systemd/system/httpd.d/. The path is corrected > to /etc/systemd/system/httpd.service.d/. > > https://fedorahosted.org/freeipa/ticket/6158 > https://bugzilla.redhat.com/show_bug.cgi?id=1362537 > > ACK It is working for me. -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 2 15:23:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 2 Aug 2016 17:23:36 +0200 Subject: [Freeipa-devel] [PATCH 33] Correct path to HTTPD's systemd service directory In-Reply-To: <59eb2164-23c1-7431-788e-72f929b3adeb@redhat.com> References: <59eb2164-23c1-7431-788e-72f929b3adeb@redhat.com> Message-ID: On 02.08.2016 17:12, Abhijeet Kasurde wrote: > > > > On 08/02/2016 08:32 PM, Christian Heimes wrote: >> Ticket #5681 and commit 586fee293f42388510fa5436af19460bbe1fdec5 changed >> the location of the ipa.conf for Apache HTTPD. The variables >> SYSTEMD_SYSTEM_HTTPD_D_DIR and SYSTEMD_SYSTEM_HTTPD_IPA_CONF point to >> the wrong directory /etc/systemd/system/httpd.d/. The path is corrected >> to /etc/systemd/system/httpd.service.d/. >> >> https://fedorahosted.org/freeipa/ticket/6158 >> https://bugzilla.redhat.com/show_bug.cgi?id=1362537 >> >> > ACK > > It is working for me. > -- > Thanks, > Abhijeet Kasurde > > IRC: akasurde > http://akasurde.github.io > > > Pushed to master: 64db0592490493a060c7983acdfdf9100d9ea813 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 2 15:27:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 2 Aug 2016 17:27:06 +0200 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: <57A0B845.5000105@redhat.com> References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> <57A0B845.5000105@redhat.com> Message-ID: On 02.08.2016 17:12, Rob Crittenden wrote: > Pavel Vomacka wrote: >> Hello, >> >> please review attached patches which Split make lint to more targets and >> add jslint > > What's the driver to split the checks out into separate targets? It is called several times during build (makes build slower), and you cannot run `make clean` in case you have wrong API.txt, because it will explode > > You are moving the makeapi and makeaci from version-update to lint. > They were in version-update for a reason: downstream builds do not > call lint. Downstream may patch code. API cannot break. Can we update downstream spec then? > > No ticket? Pavel please file tickets. > > rob > Martin^2 From pspacek at redhat.com Tue Aug 2 15:27:45 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 2 Aug 2016 17:27:45 +0200 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: <57A0B845.5000105@redhat.com> References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> <57A0B845.5000105@redhat.com> Message-ID: <0cb8fb10-244f-8f6a-f8d8-c33c2465022a@redhat.com> On 2.8.2016 17:12, Rob Crittenden wrote: > Pavel Vomacka wrote: >> Hello, >> >> please review attached patches which Split make lint to more targets and >> add jslint > > What's the driver to split the checks out into separate targets? Most importantly, makeapi and makeaci do not need to be called 10 times during single build (and can be called in parallel, once our build system can manage that). > You are moving the makeapi and makeaci from version-update to lint. They were > in version-update for a reason: downstream builds do not call lint. Downstream > may patch code. API cannot break. This is very true, I definitely agree. Even better, downstream should call as much checks as possible. This split allows the downstream spec to call all tools which are available in downstream as part of %check section of the spec, which was not possible before the split. > No ticket? -- Petr^2 Spacek From pspacek at redhat.com Tue Aug 2 15:30:30 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 2 Aug 2016 17:30:30 +0200 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: <57A0B845.5000105@redhat.com> References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> <57A0B845.5000105@redhat.com> Message-ID: <92ca2c7e-f30b-b14d-5112-3aa100a089c5@redhat.com> On 2.8.2016 17:12, Rob Crittenden wrote: > Pavel Vomacka wrote: >> Hello, >> >> please review attached patches which Split make lint to more targets and >> add jslint > > What's the driver to split the checks out into separate targets? > > You are moving the makeapi and makeaci from version-update to lint. They were > in version-update for a reason: downstream builds do not call lint. Downstream > may patch code. API cannot break. > > No ticket? Jan, can you comment on this? -- Petr^2 Spacek From pvomacka at redhat.com Tue Aug 2 15:31:44 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 2 Aug 2016 17:31:44 +0200 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> <57A0B845.5000105@redhat.com> Message-ID: <02645dd8-7a5d-9201-0a28-498de56dd9ab@redhat.com> On 08/02/2016 05:27 PM, Martin Basti wrote: > > > On 02.08.2016 17:12, Rob Crittenden wrote: >> Pavel Vomacka wrote: >>> Hello, >>> >>> please review attached patches which Split make lint to more targets >>> and >>> add jslint >> >> What's the driver to split the checks out into separate targets? > > It is called several times during build (makes build slower), and you > cannot run `make clean` in case you have wrong API.txt, because it > will explode Yes, definitely. >> >> You are moving the makeapi and makeaci from version-update to lint. >> They were in version-update for a reason: downstream builds do not >> call lint. Downstream may patch code. API cannot break. > Can we update downstream spec then? > >> >> No ticket? > Pavel please file tickets. > Yes, I will file tickets for these changes. >> >> rob >> > Martin^2 > -- Pavel^3 Vomacka From rcritten at redhat.com Tue Aug 2 15:54:15 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 2 Aug 2016 11:54:15 -0400 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: <0cb8fb10-244f-8f6a-f8d8-c33c2465022a@redhat.com> References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> <57A0B845.5000105@redhat.com> <0cb8fb10-244f-8f6a-f8d8-c33c2465022a@redhat.com> Message-ID: <57A0C227.7090609@redhat.com> Petr Spacek wrote: > On 2.8.2016 17:12, Rob Crittenden wrote: >> Pavel Vomacka wrote: >>> Hello, >>> >>> please review attached patches which Split make lint to more targets and >>> add jslint >> >> What's the driver to split the checks out into separate targets? > > Most importantly, makeapi and makeaci do not need to be called 10 times during > single build (and can be called in parallel, once our build system can manage > that). No argument there, but this is what tickets are for: to outline the problem, let the group scope it, target a release, THEN do the work. Not picking on Pavel here, but having to ask the purpose of a patch is a bad sign. I jumped in only to slow the process down so these other things could be considered. Something I might normally have done during triage. >> You are moving the makeapi and makeaci from version-update to lint. They were >> in version-update for a reason: downstream builds do not call lint. Downstream >> may patch code. API cannot break. > > This is very true, I definitely agree. Even better, downstream should call as > much checks as possible. lint is another matter. IIRC it was deemed to be less important because it is working against released code and giving the one doing the release the benefit of the doubt that they know what they are doing. It may also be that RHEL 5 or 6 didn't have pylint at the time (git may say). > This split allows the downstream spec to call all tools which are available in > downstream as part of %check section of the spec, which was not possible > before the split. %check is not appropriate for these. If you want a proper %check then get IPA installable using socket wrappers and execute the in-tree unit tests. rob From pvomacka at redhat.com Tue Aug 2 16:08:31 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 2 Aug 2016 18:08:31 +0200 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: <02645dd8-7a5d-9201-0a28-498de56dd9ab@redhat.com> References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> <57A0B845.5000105@redhat.com> <02645dd8-7a5d-9201-0a28-498de56dd9ab@redhat.com> Message-ID: On 08/02/2016 05:31 PM, Pavel Vomacka wrote: > > > On 08/02/2016 05:27 PM, Martin Basti wrote: >> >> >> On 02.08.2016 17:12, Rob Crittenden wrote: >>> Pavel Vomacka wrote: >>>> Hello, >>>> >>>> please review attached patches which Split make lint to more >>>> targets and >>>> add jslint >>> >>> What's the driver to split the checks out into separate targets? >> >> It is called several times during build (makes build slower), and you >> cannot run `make clean` in case you have wrong API.txt, because it >> will explode > Yes, definitely. So I removed moving the aci and api checks and just add jslint. >>> >>> You are moving the makeapi and makeaci from version-update to lint. >>> They were in version-update for a reason: downstream builds do not >>> call lint. Downstream may patch code. API cannot break. >> Can we update downstream spec then? >> >>> >>> No ticket? >> Pavel please file tickets. >> > Yes, I will file tickets for these changes. Also ticket is now filed: https://fedorahosted.org/freeipa/ticket/6161 >>> >>> rob >>> >> Martin^2 >> > -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0098-2-Add-jslint-into-Makefile.patch Type: text/x-patch Size: 2046 bytes Desc: not available URL: From cheimes at redhat.com Tue Aug 2 18:02:15 2016 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 2 Aug 2016 20:02:15 +0200 Subject: [Freeipa-devel] [PATCH 0032] Secure permission and cleanup Custodia server.keys In-Reply-To: References: Message-ID: <5159a7b0-7942-3a8b-ff16-94925488f303@redhat.com> On 2016-07-19 17:03, Martin Basti wrote: > > > On 12.07.2016 16:45, Christian Heimes wrote: >> Custodia's server.keys file contain the private RSA keys for encrypting >> and signing Custodia messages. The file was created with permission 644 >> and is only secured by permission 700 of the directory >> /etc/ipa/custodia. The installer and upgrader ensure that the file >> has 600. >> >> The server.keys file and all keys are now removed when during >> uninstallation of a server, too. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1353936 >> https://fedorahosted.org/freeipa/ticket/6015 >> https://fedorahosted.org/freeipa/ticket/6056 >> >> > NACK > > ipa-server-install --uninstall doesn't work I fixed it by splitting up uninstallation into two parts: 1) the server_del plugin takes care of the LDAP entries 2) CustodiaInstance.uninstall() removes the local key file -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0032-3-Secure-permission-and-cleanup-Custodia-server.keys.patch Type: text/x-patch Size: 10589 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jpazdziora at redhat.com Wed Aug 3 06:46:36 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 3 Aug 2016 08:46:36 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <20160802145738.6bajhge2pms5ukb6@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> Message-ID: <20160803064636.GR1586@redhat.com> On Tue, Aug 02, 2016 at 05:57:38PM +0300, Alexander Bokovoy wrote: > On Mon, 01 Aug 2016, Rob Crittenden wrote: > > > > How/where does the UI get a Kerberos ticket for the user? > That's indeed a problem -- even with the PKINIT support in KDC that Simo > is polishing up now, we don't have a way to obtain a ticket on behalf of > the user because Apache would terminate the SSL negotiation and we > wouldn't be able to use user's certificate to do PKINIT negotiation to > obtain a ticket as a user and then continue running on its behalf. > Neither we would get any Kerberos ticket from the client side. The current idea is to use S4U2Self and the GssapiImpersonate feature of mod_auth_gssapi 1.4.0, similar to the approach from http://www.freeipa.org/page/V4/External_Authentication/NSS_Impersonation Tibor has done the investigation for FreeIPA and is working on some polished instructions for the FreeIPA WebUI. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Wed Aug 3 07:29:52 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 3 Aug 2016 10:29:52 +0300 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <20160803064636.GR1586@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> Message-ID: <20160803072952.2ugaw5cfkd3fvntp@redhat.com> On Wed, 03 Aug 2016, Jan Pazdziora wrote: >On Tue, Aug 02, 2016 at 05:57:38PM +0300, Alexander Bokovoy wrote: >> On Mon, 01 Aug 2016, Rob Crittenden wrote: >> > >> > How/where does the UI get a Kerberos ticket for the user? >> That's indeed a problem -- even with the PKINIT support in KDC that Simo >> is polishing up now, we don't have a way to obtain a ticket on behalf of >> the user because Apache would terminate the SSL negotiation and we >> wouldn't be able to use user's certificate to do PKINIT negotiation to >> obtain a ticket as a user and then continue running on its behalf. >> Neither we would get any Kerberos ticket from the client side. > >The current idea is to use S4U2Self and the GssapiImpersonate feature >of mod_auth_gssapi 1.4.0, similar to the approach from > > http://www.freeipa.org/page/V4/External_Authentication/NSS_Impersonation > >Tibor has done the investigation for FreeIPA and is working on some >polished instructions for the FreeIPA WebUI. Got it. One thing I would correct, though, -- don't use kadmin.local, we do support setting ok_as_delegate on the service principals via IPA CLI: $ ipa service-mod --help |grep -A1 ok-as-delegate --ok-as-delegate=BOOL Client credentials may be delegated to the service -- / Alexander Bokovoy From ofayans at redhat.com Wed Aug 3 07:55:57 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 3 Aug 2016 09:55:57 +0200 Subject: [Freeipa-devel] [Test][Patch-0051] Fixed import error in replica promotion test In-Reply-To: <57728346.40000@redhat.com> References: <57728346.40000@redhat.com> Message-ID: <57A1A38D.90409@redhat.com> ping for review On 06/28/2016 04:01 PM, Oleg Fayans wrote: > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Wed Aug 3 08:36:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 3 Aug 2016 10:36:13 +0200 Subject: [Freeipa-devel] [Test][Patch-0051] Fixed import error in replica promotion test In-Reply-To: <57A1A38D.90409@redhat.com> References: <57728346.40000@redhat.com> <57A1A38D.90409@redhat.com> Message-ID: On 03.08.2016 09:55, Oleg Fayans wrote: > ping for review > > On 06/28/2016 04:01 PM, Oleg Fayans wrote: >> >> >> > ACK, if you improve commit messages From ofayans at redhat.com Wed Aug 3 09:55:52 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 3 Aug 2016 11:55:52 +0200 Subject: [Freeipa-devel] [Test][Patch-0051] Fixed import error in replica promotion test In-Reply-To: References: <57728346.40000@redhat.com> <57A1A38D.90409@redhat.com> Message-ID: <57A1BFA8.8020400@redhat.com> Hi Martin, The commit message was extended. Thanks for the review! On 08/03/2016 10:36 AM, Martin Basti wrote: > > > On 03.08.2016 09:55, Oleg Fayans wrote: >> ping for review >> >> On 06/28/2016 04:01 PM, Oleg Fayans wrote: >>> >>> >>> >> > ACK, if you improve commit messages -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0051.1-Fixed-import-error.patch Type: text/x-patch Size: 1158 bytes Desc: not available URL: From Peter.Marx at knorr-bremse.com Wed Aug 3 10:39:49 2016 From: Peter.Marx at knorr-bremse.com (Marx, Peter) Date: Wed, 3 Aug 2016 10:39:49 +0000 Subject: [Freeipa-devel] certmonger proxy configuration not possible ? Message-ID: <2C720BBFE8885346B9A4377911BABE7886889266@MUCS72046.corp.knorr-bremse.com> Hi, i have to access an external PKI server with SCEP protocol through our corporate proxy. On command line I can set the proxy and trigger a CSR with the scep-submit helper successfully. But same operation with getcert fails, as there is no proxy configuration possibility in e.g. certmonger.conf. How can I work around this ? Peter Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheimes at redhat.com Wed Aug 3 11:42:13 2016 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 3 Aug 2016 13:42:13 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: <5e7f167e-b5d3-fd5a-1ec0-599df9ce0b31@redhat.com> References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> <9751cf00-78b4-0dfd-4c70-7a04cb930215@redhat.com> <5e7f167e-b5d3-fd5a-1ec0-599df9ce0b31@redhat.com> Message-ID: <0b7f3090-5d9d-7044-2520-93361117c1c1@redhat.com> On 2016-07-07 14:54, Martin Basti wrote: > Patch needs changes in ipa-4-3 branch Here are patches for master and ipa-4-3 branch. I have rebased both patches to head. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0031-2-RedHatCAService-should-wait-for-local-Dogtag-instanc.patch Type: text/x-patch Size: 1518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0031-RedHatCAService-should-wait-for-local-Dogtag-instance-4.3.patch Type: text/x-patch Size: 1576 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkupka at redhat.com Wed Aug 3 11:44:32 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 3 Aug 2016 13:44:32 +0200 Subject: [Freeipa-devel] [PATCH 0114] vault: Catch correct exception in decrypt Message-ID: <8c3f1f3b-00cc-01a3-6296-7f7510012a07@redhat.com> Pushed under one-liner rule, attaching path for reference. Pushed to master: 8ab0ad5b9ef59eca7b25a150baeb4a9bf8faa582 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0114.0-vault-Catch-correct-exception-in-decrypt.patch Type: text/x-patch Size: 928 bytes Desc: not available URL: From mbasti at redhat.com Wed Aug 3 12:17:30 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 3 Aug 2016 14:17:30 +0200 Subject: [Freeipa-devel] Broken IPA installations on F24 Message-ID: <319d85d8-8d1d-6221-bc09-7ee81328abc7@redhat.com> Hello all, update resteasy-*-3.0.17 from updates-testing prevents IPA (PKI CA) to be installed on f24, ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpEQulGP' returned non-zero exit status 1 ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation logs and the following files/directories for more information: ipa.ipaserver.install.cainstance.CAInstance: CRITICAL /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration failed. ipa.ipapython.install.cli.install_tool(Server): ERROR CA configuration failed. ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information Workaround: # dnf downgrade resteasy-atom-provider resteasy-client resteasy-core resteasy-jackson-provider resteasy-jaxb-provider --allowerasing Please provide negative karma, we must prevent this to get into updates, it will break IPA 4.3 on F24: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d80872c309 Regards Martin^2 From ofayans at redhat.com Wed Aug 3 12:45:35 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 3 Aug 2016 14:45:35 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> Message-ID: <57A1E76F.9@redhat.com> Hi Martin, Thanks for the review! Both patches were updated. On 07/28/2016 04:11 PM, Martin Basti wrote: > > > On 08.07.2016 15:41, Oleg Fayans wrote: >> Hi Martin, >> >> Thanks for the review! >> >> On 07/08/2016 02:18 PM, Martin Basti wrote: >>> >>> >>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>> Hi guys, >>>> >>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed before >>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>> feature. >>>> >>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>> One more test was added to the patch-0048 >>>>> >>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>> Fixed a bug in the previous patch, automated 2 more testcases from >>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>> >>>>>> >>>>>> >>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> IIUC, this will turn off the machine completely, how is cleanup done >>> then. AFAIK our tests cannot turn on machine again and run cleanup, so >>> you will not be able to run more tests on the same topology without >>> manual cleanup and manual start. >>> >>> + replica = self.replicas[0] >>> + replica.run_command(['poweroff']) >>> >>> IMO would be better to just call 'ipactl stop' instead of 'poweroff' >> >> Agreed! Fixed. >> >>> >>> Martin^2 >>> >> >> >> > *Automated ipa-replica-manage del tests* > > 1) > + replica.run_command(['ipactl', 'stop']) > + time.sleep(3) > > Why do you need sleep here? Removed, it was left from the old "poweroff" approach > > > 2) > + ruvid_re = re.compile(".*%s:389: (\d+).*" % replica.hostname) > + replica_ruvs = ruvid_re.findall(result.stdout_text) > + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', > + '-p', master.config.dirman_password, > + replica_ruvs[0]]) > > Because you are using re.findall(), without any match you will receive > IndexError here replica_ruvs[0]. IMO it deserves assert before Implemented the assert which checks that the output contains enough replica RUVs > > 3) > assert(replica.hostname in result1.stdout_text) > > I think that this is error prone. What if there is just error 'could not > connect to replica ', or something similar. instead of > listing/cleaning/whatever operation was executed. I think that it should > be more specific regexp than just finding a replica name substring (Yes > In IPA we dont always print error so stderr) > > I'm not sure, but probably there might be cases when non critical error > happen and exist status is still 0 Agree. Implemented a regex-based search > > 4) > > + replica.run_command(['poweroff']) > + time.sleep(3) > > There should not be poweroff, probably sleep could be removed too. Gone > > > * Automated clean-ruv subcommand test* > > 1) PEP8, 2 new lines expected > ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 > blank lines, found 0 > ./ipatests/test_integration/test_topology.py:182:80: E501 line too long > (85 > 79 characters) Fixed > > > 2) > I dont like doing assert just with count of occurences of substring in > STDOUT, would be possible to improve this somehow? Maybe, but frankly, I don't see how. In this case we are making sure that both simple and CA-specific RUVs of a replica are displayed. The format of the output is strict: Replica Update Vectors: replica1_hostname:389: RUV_id replica2_hostname:389: RUV_id Certificate Server Replica Update Vectors: replica1_hostname:389: RUV_id replica2_hostname:389: RUV_id If we do not see 2 occurrences of the replica hostname than definitely something went wrong > > 3) > I'm not sure if clean-ruv is instant operations or there is some magic > happening in background (we have abort-clean-ruv). Maybe some sleep > should be there, but this needs investigation. > > + assert(replica.hostname in result2.stdout_text), ( > + "The wrong RUV was deleted") > + result3 = master.run_command(['ipa-replica-manage', 'list-ruv', > + '-p', master.config.dirman_password]) > + assert(result3.stdout_text.count(replica.hostname) == 1), ( > + "CA RUV of the replica is still displayed") > Based on my discussion with Stanislav Laznicka, I understood that by default clean-ruv does not return the shell until the operation is finished. You can force dropping into the shell by pressing CTRL+C, in which case the background job will still be running, but this is not the default behavior -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0047.2-Automated-clean-ruv-subcommand-test.patch Type: text/x-patch Size: 3675 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0048.3-Automated-ipa-replica-manage-del-tests.patch Type: text/x-patch Size: 4659 bytes Desc: not available URL: From blipton at redhat.com Wed Aug 3 13:21:58 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 3 Aug 2016 09:21:58 -0400 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> Message-ID: <837d2da8-d6ad-912a-2b72-a39e9cb87d15@redhat.com> On 08/01/2016 11:57 PM, Fraser Tweedale wrote: > On Fri, Jul 29, 2016 at 11:13:16AM -0400, Ben Lipton wrote: >> On 07/29/2016 09:39 AM, Petr Spacek wrote: >>> On 27.7.2016 19:06, Ben Lipton wrote: >>>> Hi all, >>>> >>>> I think the automatic CSR generation feature >>>> (https://fedorahosted.org/freeipa/ticket/4899, >>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation) is >>>> stable enough to review now. The following are summaries of the attached patches: >>>> 0004: LDAP schema changes for the new feature >>>> 0005: Basic API for new objects and CSR generation >>>> 0006: Update install automation to create some default mapping rules >>>> 0007: Implement the lookups and text processing that generates the CSR config >>>> 0008 and 0009: Implement some actual transformation rules so that the feature >>>> is usable >>>> 0010: Add a new cert profile for user certs, with mappings >>>> 0011: Implement import/export of cert profiles with mappings >>>> 0012: Tests for profile import/export >>>> >>>> Generally speaking, later patches depend on earlier ones, but I don't >>>> anticipate any problems from committing earlier patches without later ones. >>>> >>>> If you prefer, you can also comment on the pull request version: >>>> https://github.com/LiptonB/freeipa/pull/4. Note that I may force push on this >>>> branch. >>>> >>>> Allocation of OIDs for schema change also needs review: >>>> https://code.engineering.redhat.com/gerrit/#/c/80061/ >>>> >>>> Known issues: >>>> - When the requested principal does not have some of the requested data, >>>> produces funny-looking configs with extra commas, empty sections, etc. They >>>> are still accepted by my copies of openssl and certutil, but they look ugly. >>>> - The new objects don't have any ACIs, so for the moment only admin can run >>>> the new commands. >>>> - Does not yet have support for prompting user for field values, so currently >>>> all data must come from the database. >>>> - All processing happens on the server side. As discussed in a previous >>>> thread, it would be desirable to break this out into a library so it could be >>>> used client-side. >>>> >>>> Very excited to hear your thoughts! >>> Hi Ben, >>> >>> I wanted to give it a try from user's point of view first, before diving into >>> implementation details. Here are some observations: >> Thanks for giving it a try! This is great feedback. >>> 0. Design pages are using term "helper" and it is used even as option in the >>> example with smartcards. Please fix either design page or the code so they are >>> consistent. >> Good point. In a previous discussion, Alexander remarked that --helper >> sounded too low-level, but I find that --use sounds very generic and >> --format doesn't make a lot of sense for ipa cert-request, which never >> actually gives you the config that's generated. So if they're all going to >> be the same word, which is probably a good idea, I might be leaning towards >> --helper, but I'm interested to hear opinions on this. >>> 1. The "ipa cert-request" command is missing options --autofill and --use (aka >>> helper aka format :-) which are mentioned in the design pages. >> Yeah, I haven't managed to implement much of the UI niceness suggested by >> the design page. I probably should have mentioned that in the email - all >> that I expect to be working at this point is 'ipa cert-get-requestdata' and >> CRUD for the mapping rules/profiles themselves. >>> 2. "ipa cert_get_requestdata" command passes even without --profile-id and >>> generates empty config. I think that this is not expected :-) >> More expected than you might think :) I'm guessing what's happening is that >> you're passing a user principal and it's defaulting to the caIPAserviceCert >> profile, then failing to fill out any of the fields because the data it >> needs is not there. I agree this isn't great. I was planning to address this >> by having it throw an error if it can't generate at least the subject of the >> request, and maybe suggest using a different profile. >> >> I chose to have it default to caIPAserviceCert because that's what ipa >> cert-request does, but maybe that's not as predictable as I thought. >> > In general use I think that 'caIPAserviceCert' is unlikely to be > used a majory of the time, and it is a new command so there are no > compatibility issues; therefore why not make the profile option > mandatory? Fair enough. Ok, a modified patch that changes this (and fixes some label errors I noticed) is attached. > >>> 3. "ipa cert_get_requestdata --format=openssl" prints the text to stdout >>> including label "Configuration file contents:". This is hard to use because >>> simple redirection like "ipa cert_get_requestdata --format=openssl > config" >>> will not give you valid OpenSSL config file - it needs hand-editing. >>> >>> It would be good to add --out parameter you envisioned in the design page. >>> Please ask jcholast for proper name and semantics :-) With --out option the >>> command can be used to generate valid config (or script if certutil was selected). >> Agreed. Another example of the UI not being quite right yet. I've been >> unsure how to handle this, because of certutil taking a command line and >> openssl a config file. It actually gets even more complicated because, as >> you point out in the next item, openssl also needs a command in addition to >> the config file. I'm interested in thinking about how to handle this cleanly >> from a user perspective. Generating a script, or providing the command lines >> as hints, might be ways to get around these concerns. >>> 4. "ipa cert_get_requestdata --format=openssl" could print hint what OpenSSL >>> command should be executed on the generated config file. For testing I've used >>> command "openssl req -new -out csr -text -config config" (stolen and modified >>> from smart card example). Also, as a second hint, it could print the IPA >>> command which needs to be used to sign the CSR generated by the helper. >> Also agreed, the framework should be able to generate and (for purposes of >> 'ipa cert-request --autofill') even execute the command required to make the >> CSR. >> >>> 5. My naive attempt to get userCert for admin failed: >>> $ ipa cert_get_requestdata --format=openssl --principal=admin >>> --profile-id=userCert > usercert.conf >>> # remove the trailing label >>> $ openssl req -new -out csr -text -config usercert.conf >>> $ ipa cert-request --principal=admin --profile-id=userCert usercert.csr >>> ipa: ERROR: invalid 'csr': No Common Name was found in subject of request. >>> >>> I'm attaching files generated by the commands above. I did not modify anything >>> in the templates or profiles, just tried to use the new profile added by >>> freeipa-blipton-0010-Add-a-new-cert-profile-for-users.patch . >> Hah! This is what I get for thinking I know what the output has to look >> like, and not testing all the way through to requesting the cert. I'll >> change the profile to generate a subject with CN= instead of UID=. Updated >> patch is attached. Unfortunately these rules are only updated at >> ipa-server-install time, so if you'd like to fix it without reinstalling: >> > (Tangential commentary...) Yeah, currently cert-request demands the > CN. There is a design to relax the requirement to handle empty > subject names (look at SAN only). IMO it would make sense to accept > other "obvious" mappings in Subject DN like accepting UID instead of > CN for user subjects, but that would be a separate RFE. Noone has > actually asked for it yet :) > > Cheers, > Fraser > >> ipa certtransformationrule-mod dataUsernameCN dataUsernameCertutil >> --template 'CN={{ipa.datafield(subject.uid.0)|quote}},{{ipa.datafield(config.ipacertificatesubjectbase.0)|quote}}' >> ipa certtransformationrule-mod dataUsernameCN dataUsernameOpenssl --template >> '{{ipa.datafield(config.ipacertificatesubjectbase.0)}} >> CN={{ipa.datafield(subject.uid.0)}}' >> Yes, that must be an actual linebreak between the subjectbase and the CN in >> the openssl one. I know :-/ >> >>> Hopefully I will get to other things soon (but not this week). >>> >>> >>> Anyway, all this seems like (expected) initial problems. In general the first >>> touch with user interface seems reasonable and needs only small improvements. >>> >>> Good work! >>> -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0005-2-Add-plugin-for-CSR-generation.patch Type: text/x-patch Size: 20499 bytes Desc: not available URL: From mbasti at redhat.com Wed Aug 3 13:31:59 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 3 Aug 2016 15:31:59 +0200 Subject: [Freeipa-devel] [Test][Patch-0051] Fixed import error in replica promotion test In-Reply-To: <57A1BFA8.8020400@redhat.com> References: <57728346.40000@redhat.com> <57A1A38D.90409@redhat.com> <57A1BFA8.8020400@redhat.com> Message-ID: On 03.08.2016 11:55, Oleg Fayans wrote: > Hi Martin, > > The commit message was extended. Thanks for the review! > > On 08/03/2016 10:36 AM, Martin Basti wrote: >> >> >> On 03.08.2016 09:55, Oleg Fayans wrote: >>> ping for review >>> >>> On 06/28/2016 04:01 PM, Oleg Fayans wrote: >>>> >>>> >>>> >>> >> ACK, if you improve commit messages > Pushed to master: 4e574cde72da159dc2e5511f23c9f6b3c762e8f5 From mbasti at redhat.com Wed Aug 3 13:37:17 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 3 Aug 2016 15:37:17 +0200 Subject: [Freeipa-devel] [PATCH 0559] Increase default length of auto-generated passwords In-Reply-To: <20160729161915.mnmnwo2pqvp35gvu@redhat.com> References: <20160729150957.d5cfwp6xbleir5nt@redhat.com> <4320f103-3632-e45e-31c7-a7b94375acb3@redhat.com> <20160729161915.mnmnwo2pqvp35gvu@redhat.com> Message-ID: <751ac438-2cde-ed5a-abc8-470efdfd1647@redhat.com> On 29.07.2016 18:19, Alexander Bokovoy wrote: > On Fri, 29 Jul 2016, Martin Basti wrote: >> >> >> On 29.07.2016 17:09, Alexander Bokovoy wrote: >> > On Fri, 29 Jul 2016, Martin Basti wrote: >> > > https://fedorahosted.org/freeipa/ticket/6116 >> > > > > > > Patch attached >> > > > > > From ca5305e032137b7c9197d0c1050191079a72124e Mon Sep 17 >> 00:00:00 2001 >> > > From: Martin Basti >> > > Date: Fri, 22 Jul 2016 16:41:29 +0200 >> > > Subject: [PATCH] Increase default length of auto generated passwords >> > > > > Installer/IPA generates passwords for warious purpose: >> > > * KRA >> > > * kerberos master key >> > > * NSSDB password >> > > * temporary passwords during installation >> > > > > Length of passwords should be increased to 22, ~128bits of >> entropy, to >> > > be safe nowadays. >> > > > > https://fedorahosted.org/freeipa/ticket/6116 >> > ACK with a minor comment. >> > > > --- >> > > ipapython/ipautil.py | 2 +- >> > > ipaserver/plugins/baseuser.py | 3 ++- >> > > ipaserver/plugins/host.py | 3 ++- >> > > ipaserver/plugins/stageuser.py | 3 ++- >> > > ipaserver/plugins/user.py | 3 ++- >> > > 5 files changed, 9 insertions(+), 5 deletions(-) >> > > > > diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py >> > > index >> 9964fba4f694b57242b3bd3065a418917d977533..ca7e81d666cd6c345bdbbf4660c3451ac1f2c045 >> > > 100644 >> > > --- a/ipapython/ipautil.py >> > > +++ b/ipapython/ipautil.py >> > > @@ -57,7 +57,7 @@ from ipapython.dn import DN >> > > SHARE_DIR = paths.USR_SHARE_IPA_DIR >> > > PLUGINS_SHARE_DIR = paths.IPA_PLUGINS >> > > > > -GEN_PWD_LEN = 12 >> > > +GEN_PWD_LEN = 22 >> > It would be good to add a temporary password constant too >> > +GEN_TMP_PWD_LEN = 12 >> > > and then use it instead of pwd_len=12 below. >> > > > # Having this in krb_utils would cause circular import >> > > KRB5_KDC_UNREACH = 2529639068 # Cannot contact any KDC for >> requested > > realm >> > > diff --git a/ipaserver/plugins/baseuser.py > > >> b/ipaserver/plugins/baseuser.py >> > > index >> e4288a5a131157815ffb2452692a7edb342f6ac3..5e0752c8d3d246fa7c283f05b82ef01de2e5bf34 >> > > 100644 >> > > --- a/ipaserver/plugins/baseuser.py >> > > +++ b/ipaserver/plugins/baseuser.py >> > > @@ -552,7 +552,8 @@ class baseuser_mod(LDAPUpdate): >> > > > > def check_userpassword(self, entry_attrs, **options): >> > > if 'userpassword' not in entry_attrs and >> options.get('random'): >> > > - entry_attrs['userpassword'] = > > >> ipa_generate_password(baseuser_pwdchars) >> > > + entry_attrs['userpassword'] = ipa_generate_password( >> > > + baseuser_pwdchars, pwd_len=12) >> > > # save the password so it can be displayed in >> post_callback >> > > setattr(context, 'randompassword', > > >> entry_attrs['userpassword']) >> > > > > diff --git a/ipaserver/plugins/host.py >> b/ipaserver/plugins/host.py >> > > index >> 413dcf15e0423170d8334902b9dcf8fb5aa14de6..1cefb6224e1a6dad0080369edee35c4524e5bd39 >> > > 100644 >> > > --- a/ipaserver/plugins/host.py >> > > +++ b/ipaserver/plugins/host.py >> > > @@ -683,7 +683,8 @@ class host_add(LDAPCreate): >> > > if 'krbprincipal' in entry_attrs['objectclass']: >> > > entry_attrs['objectclass'].remove('krbprincipal') >> > > if options.get('random'): >> > > - entry_attrs['userpassword'] = > > >> ipa_generate_password(characters=host_pwd_chars) >> > > + entry_attrs['userpassword'] = ipa_generate_password( >> > > + characters=host_pwd_chars, pwd_len=12) >> > > # save the password so it can be displayed in >> post_callback >> > > setattr(context, 'randompassword', > > >> entry_attrs['userpassword']) >> > > certs = options.get('usercertificate', []) >> > > diff --git a/ipaserver/plugins/stageuser.py > > >> b/ipaserver/plugins/stageuser.py >> > > index >> 3b9388f6020b9a6c40caedd36f3640a05a13da65..6df189c3913171b4990ce115b296b19c7447592d >> > > 100644 >> > > --- a/ipaserver/plugins/stageuser.py >> > > +++ b/ipaserver/plugins/stageuser.py >> > > @@ -339,7 +339,8 @@ class stageuser_add(baseuser_add): >> > > > > # If requested, generate a userpassword >> > > if 'userpassword' not in entry_attrs and >> options.get('random'): >> > > - entry_attrs['userpassword'] = > > >> ipa_generate_password(baseuser_pwdchars) >> > > + entry_attrs['userpassword'] = ipa_generate_password( >> > > + baseuser_pwdchars, pwd_len=12) >> > > # save the password so it can be displayed in >> post_callback >> > > setattr(context, 'randompassword', > > >> entry_attrs['userpassword']) >> > > > > diff --git a/ipaserver/plugins/user.py >> b/ipaserver/plugins/user.py >> > > index >> b3ae7646fdcfa1dce10d90063dae2a24c091e8ee..62ec529062c7ac39661df2a8c3d2277711268b11 >> > > 100644 >> > > --- a/ipaserver/plugins/user.py >> > > +++ b/ipaserver/plugins/user.py >> > > @@ -517,7 +517,8 @@ class user_add(baseuser_add): >> > > entry_attrs['gidnumber'] = group_attrs['gidnumber'] >> > > > > if 'userpassword' not in entry_attrs and >> options.get('random'): >> > > - entry_attrs['userpassword'] = > > >> ipa_generate_password(baseuser_pwdchars) >> > > + entry_attrs['userpassword'] = ipa_generate_password( >> > > + baseuser_pwdchars, pwd_len=12) >> > > # save the password so it can be displayed in >> post_callback >> > > setattr(context, 'randompassword', > > >> entry_attrs['userpassword']) >> > > > > -- > > 2.5.5 >> > > > > > -- > > Manage your subscription for the Freeipa-devel >> mailing list: >> > > https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code >> > > Thanks >> Updated patch attached > Thanks, ACK. > Pushed to master: 51ccde25f7ec0d5309c52b5349992652c7e17a01 From rcritten at redhat.com Wed Aug 3 13:51:38 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 3 Aug 2016 09:51:38 -0400 Subject: [Freeipa-devel] certmonger proxy configuration not possible ? In-Reply-To: <2C720BBFE8885346B9A4377911BABE7886889266@MUCS72046.corp.knorr-bremse.com> References: <2C720BBFE8885346B9A4377911BABE7886889266@MUCS72046.corp.knorr-bremse.com> Message-ID: <57A1F6EA.9080901@redhat.com> Marx, Peter wrote: > Hi, > > i have to access an external PKI server with SCEP protocol through our > corporate proxy. On command line I can set the proxy and trigger a CSR > with the scep-submit helper successfully. What are you setting, environment variables I assume? > But same operation with getcert fails, as there is no proxy > configuration possibility in e.g. certmonger.conf. > > How can I work around this ? A quick kludge might be to replace scep-submit with a shell script that exports the proxy config and then calls the real scep-submit. A perhaps better and more supportable idea would be to add a CA pointing to this new helper, something like: getcert add-ca -c exampleSCEPca -e \ "/usr/libexec/certmonger/scep-submit-proxy -u http://ca.example.com/cgi-bin/pkiclient.exe" So scep-submit-proxy would setup the environment and call scep-submit. rob > > Peter > > > > Knorr-Bremse IT-Services GmbH > Sitz: M?nchen > Gesch?ftsf?hrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald > Schneider > Registergericht M?nchen, HR B 167 268 > > This transmission is intended solely for the addressee and contains > confidential information. > If you are not the intended recipient, please immediately inform the > sender and delete the message and any attachments from your system. > Furthermore, please do not copy the message or disclose the contents to > anyone unless agreed otherwise. To the extent permitted by law we shall > in no way be liable for any damages, whatever their nature, arising out > of transmission failures, viruses, external influence, delays and the like. > > From dkupka at redhat.com Wed Aug 3 14:23:32 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 3 Aug 2016 16:23:32 +0200 Subject: [Freeipa-devel] [PATCH 0112-7] Speeding up cli help In-Reply-To: <01ff40a4-b964-4f78-33dd-f1c92c490fdd@redhat.com> References: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> <01ff40a4-b964-4f78-33dd-f1c92c490fdd@redhat.com> Message-ID: On 21/07/16 10:12, Jan Cholasta wrote: > Hi, > > On 20.7.2016 14:32, David Kupka wrote: >> On 15/07/16 12:53, David Kupka wrote: >>> Hello! >>> >>> After Honza introduced thin client that builds plugins and commands >>> dynamically from schema client became much slower. This is only logical, >>> instead of importing a module client now must fetch the schema from >>> server, parse it and instantiate the commands using the data. >>> >>> First step to speed it up was addition of schema cache to client. That >>> removed the RTT and download time of fetching schema every time. >>> >>> Now the most time consuming task became displaying help for lists of >>> topics and command and displaying individual topics. This is simply >>> because of the need to instantiate all the commands to find the >>> relations between topics and commands. >>> >>> All the necessary bits for server commands and topics are already in the >>> schema cache so we can skip this part and generate help from it, right? >>> Not so fast! >>> >>> There are client plugins with commands and topics. So we can generate >>> basic bits (list of all topics, list of all commands, list of commands >>> for each topic) from schema and store it in cache. Then we need to go >>> through all client plugins and get similar bits for client plugins. Then >>> we can merge and print. >>> >>> Still the client response is not as fast as before and I this it even >>> can't be. Also first time you display particular topic or list takes >>> longer because it must be freshly generated and stored in cache for next >>> use. And this is what the attached patches do. >>> >>> https://fedorahosted.org/freeipa/ticket/6048 >> >> Reimplemented so there is no need to distinguish client plugins and >> remote plugins. >> The main idea of this approach is to avoid creating instances of the >> commands just to get the information about topic, name and summary >> needed for displaying help. Instead class properties are used to access >> the information directly in schema. > > Patch 0112: > > I think this would better be done in Schema.read_namespace_member, > because Schema is where all the state is. > > (BTW does _SchemaNameSpace.__getitem__ raise KeyError for non-existent > keys? It looks like it doesn't.) > > > Patch 0113: > > How about setting _schema_cached to False in Schema.__init__() rather > that getattr()-ing it in _ensure_cached()? > > > Patch 0116: > > ClientCommand.doc should be a class property as well, otherwise .summary > won't work on it correctly. > > _SchemaCommand.doc should not be a property, as it's not needed for > .summary to work on it correctly. > > > Otherwise works fine for me. > > Honza > Updated patches attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0112.2-schema-Speed-up-schema-cache.patch Type: text/x-patch Size: 14439 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0113.2-frontend-Change-doc-summary-topic-and-NO_CLI-to-clas.patch Type: text/x-patch Size: 12124 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0115.2-schema-Introduce-schema-cache-format.patch Type: text/x-patch Size: 1493 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0116.2-schema-Generate-bits-for-help-load-them-on-request.patch Type: text/x-patch Size: 5940 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0117.2-help-Do-not-create-instances-to-get-information-abou.patch Type: text/x-patch Size: 2807 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0118.2-compat-Save-server-s-API-version-in-for-pre-schema-s.patch Type: text/x-patch Size: 10292 bytes Desc: not available URL: From jcholast at redhat.com Wed Aug 3 14:33:18 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 3 Aug 2016 16:33:18 +0200 Subject: [Freeipa-devel] [PATCH 0112-7] Speeding up cli help In-Reply-To: References: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> <01ff40a4-b964-4f78-33dd-f1c92c490fdd@redhat.com> Message-ID: <29310e45-fc18-52fc-1686-651bb42480c9@redhat.com> On 3.8.2016 16:23, David Kupka wrote: > On 21/07/16 10:12, Jan Cholasta wrote: >> Hi, >> >> On 20.7.2016 14:32, David Kupka wrote: >>> On 15/07/16 12:53, David Kupka wrote: >>>> Hello! >>>> >>>> After Honza introduced thin client that builds plugins and commands >>>> dynamically from schema client became much slower. This is only >>>> logical, >>>> instead of importing a module client now must fetch the schema from >>>> server, parse it and instantiate the commands using the data. >>>> >>>> First step to speed it up was addition of schema cache to client. That >>>> removed the RTT and download time of fetching schema every time. >>>> >>>> Now the most time consuming task became displaying help for lists of >>>> topics and command and displaying individual topics. This is simply >>>> because of the need to instantiate all the commands to find the >>>> relations between topics and commands. >>>> >>>> All the necessary bits for server commands and topics are already in >>>> the >>>> schema cache so we can skip this part and generate help from it, right? >>>> Not so fast! >>>> >>>> There are client plugins with commands and topics. So we can generate >>>> basic bits (list of all topics, list of all commands, list of commands >>>> for each topic) from schema and store it in cache. Then we need to go >>>> through all client plugins and get similar bits for client plugins. >>>> Then >>>> we can merge and print. >>>> >>>> Still the client response is not as fast as before and I this it even >>>> can't be. Also first time you display particular topic or list takes >>>> longer because it must be freshly generated and stored in cache for >>>> next >>>> use. And this is what the attached patches do. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6048 >>> >>> Reimplemented so there is no need to distinguish client plugins and >>> remote plugins. >>> The main idea of this approach is to avoid creating instances of the >>> commands just to get the information about topic, name and summary >>> needed for displaying help. Instead class properties are used to access >>> the information directly in schema. >> >> Patch 0112: >> >> I think this would better be done in Schema.read_namespace_member, >> because Schema is where all the state is. >> >> (BTW does _SchemaNameSpace.__getitem__ raise KeyError for non-existent >> keys? It looks like it doesn't.) >> >> >> Patch 0113: >> >> How about setting _schema_cached to False in Schema.__init__() rather >> that getattr()-ing it in _ensure_cached()? >> >> >> Patch 0116: >> >> ClientCommand.doc should be a class property as well, otherwise .summary >> won't work on it correctly. >> >> _SchemaCommand.doc should not be a property, as it's not needed for >> .summary to work on it correctly. >> >> >> Otherwise works fine for me. >> >> Honza >> > > Updated patches attached. Thanks, ACK. Pushed to master: 229e2a1ed9ea9877cb5e879fadd99f9040f77c96 -- Jan Cholasta From Peter.Marx at knorr-bremse.com Wed Aug 3 14:44:48 2016 From: Peter.Marx at knorr-bremse.com (Marx, Peter) Date: Wed, 3 Aug 2016 14:44:48 +0000 Subject: [Freeipa-devel] certmonger proxy configuration not possible ? In-Reply-To: <57A1F6EA.9080901@redhat.com> References: <2C720BBFE8885346B9A4377911BABE7886889266@MUCS72046.corp.knorr-bremse.com> <57A1F6EA.9080901@redhat.com> Message-ID: <2C720BBFE8885346B9A4377911BABE78868899B8@MUCS72046.corp.knorr-bremse.com> clever idea - I'll try that. Thanks Peter -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, August 03, 2016 3:52 PM To: Marx, Peter; 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certmonger proxy configuration not possible ? Marx, Peter wrote: > Hi, > > i have to access an external PKI server with SCEP protocol through our > corporate proxy. On command line I can set the proxy and trigger a > CSR with the scep-submit helper successfully. What are you setting, environment variables I assume? > But same operation with getcert fails, as there is no proxy > configuration possibility in e.g. certmonger.conf. > > How can I work around this ? A quick kludge might be to replace scep-submit with a shell script that exports the proxy config and then calls the real scep-submit. A perhaps better and more supportable idea would be to add a CA pointing to this new helper, something like: getcert add-ca -c exampleSCEPca -e \ "/usr/libexec/certmonger/scep-submit-proxy -u http://ca.example.com/cgi-bin/pkiclient.exe" So scep-submit-proxy would setup the environment and call scep-submit. rob > > Peter > > > > Knorr-Bremse IT-Services GmbH > Sitz: M?nchen > Gesch?ftsf?hrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald > Schneider Registergericht M?nchen, HR B 167 268 > > This transmission is intended solely for the addressee and contains > confidential information. > If you are not the intended recipient, please immediately inform the > sender and delete the message and any attachments from your system. > Furthermore, please do not copy the message or disclose the contents > to anyone unless agreed otherwise. To the extent permitted by law we > shall in no way be liable for any damages, whatever their nature, > arising out of transmission failures, viruses, external influence, delays and the like. > > automechanika - 13.09.-17.09.2016 - Messe Frankfurt - Hall 3.0 - Stand G98 + E91 InnoTrans - 20.09.-23.09.2016 - Messe Berlin - Hall 1.2b - Stand 104 + 210 IAA - 22.09.-29.09.2016 - Messe Hannover - Hall 17 - Stand A30 Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. From mbasti at redhat.com Wed Aug 3 15:49:01 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 3 Aug 2016 17:49:01 +0200 Subject: [Freeipa-devel] [PATCH] 0013 Fix ipa hbactest output In-Reply-To: References: Message-ID: <280c85d0-648f-4ffd-e4ae-993f8b71578f@redhat.com> On 02.08.2016 13:22, Florence Blanc-Renaud wrote: > Hi, > > please find attached a patch related to 'ipa hbactest' producing a > Traceback. > > https://fedorahosted.org/freeipa/ticket/6157 > > Flo. > > Hello Flo, 1) can you please move that check, right bellow the for? for o in self.output: + if o == 'value': + continue It is peformance improvements :) We should not waste time with getting values from dict if we will not use them 2) elif isinstance(result, (unicode, bool)): if o == 'summary': textui.print_summary(result) else: textui.print_indented(result) Here you should remove the 'bool' from isinstance or update print_indented to allow work with boolean (I prefer the first one). Because with any other bool value it will fail again. Thanks, Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Aug 3 16:10:45 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 3 Aug 2016 18:10:45 +0200 Subject: [Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install In-Reply-To: <5af4f271-4add-ea82-2179-c9357fdac3d9@redhat.com> References: <4975c47e-ce78-9e73-7849-f0d77909db7f@redhat.com> <2337c1e9-8d5a-8329-4e11-426b7f231839@redhat.com> <235931cd-67d6-6266-06cb-bd294395e1f3@redhat.com> <5af4f271-4add-ea82-2179-c9357fdac3d9@redhat.com> Message-ID: On 07/13/2016 12:36 PM, Stanislav Laznicka wrote: > On 07/13/2016 09:51 AM, Petr Vobornik wrote: >> On 07/13/2016 08:26 AM, Stanislav Laznicka wrote: >>> On 07/12/2016 08:44 AM, Stanislav Laznicka wrote: >>>> On 07/11/2016 04:27 PM, Petr Vobornik wrote: >>>>> On 07/11/2016 01:23 PM, Stanislav Laznicka wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/6046 >>>>>> >>>>>> >>>>>> >>>>> Isn't the bug about something else? >>>>> >>>>> The issue was that ipa-replica-install doesn't have --force-ntpd >>>>> option. >>>>> It is an option of ipa-client-install which is run from replica >>>>> installer. >>>>> >>>>> The unattended mode is unrelated. >>>> My understanding is that the bug says that '--force-ntpd' option >>>> should not be shown when ipa-client-install is run during replica >>>> installation. >>>> >>>> During replica installation, the ipa-client-install script is run with >>>> the '--unattended' flag in the 'ensure_enrolled()' function. Being a >>>> separate script, there's not many options on how to pass the >>>> information not to show the message to ipa-client-install. Using the >>>> already used flag to get rid of the message seemed easiest to me. >>>> Introducing a new 'hidden' flag (like '--from-replica'), on the other >>>> hand, seems a bit harsh. >>>> >>> Just to throw it out there - it's possible that the '--force-join' >>> client option would also appear as a hint from the client install script >>> (during replica installation). Should this also be muted somehow? To me, >>> it seems reasonable to rather add it as an argument to >>> ipa-replica-install to pass it to the client install script. >>> >> IMO client installation initiated from replica needs to have a special >> option(hidden in help) similar to --on-server (or what's its name). E.g. >> the name can be --replica-install. Maybe --on-server can be used but it >> may have other implication which might not be valid for this use case. >> >> Anything else are just workarounds. Imagine that admin runs >> ipa-client-install with --unattended or --force-join. He would then not >> get the message as now. > Reviving thread to get other opinion. > The --on-master option won't do here as it seems that the client would > require some IPA pre-configuration for successful install. A new option > will have to be created, then. I'm for new "hidden" option. > > As I was trying to point out, the situation about --force-join is a bit > different. The option again would be shown and is not available in > ipa-replica-install. I think it should be available to allow direct > replica installation even when previous installation failed/left some > mess on the master (ofc the user could run `ipa-replica-manage del > --cleanup` on the master instead). > That could work but imho is out of scope of this ticket. -- Petr Vobornik From mbasti at redhat.com Wed Aug 3 17:18:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 3 Aug 2016 19:18:44 +0200 Subject: [Freeipa-devel] [PATCH 0032] Secure permission and cleanup Custodia server.keys In-Reply-To: <5159a7b0-7942-3a8b-ff16-94925488f303@redhat.com> References: <5159a7b0-7942-3a8b-ff16-94925488f303@redhat.com> Message-ID: <72042d4c-cd89-b30c-dc35-679360d96e0c@redhat.com> On 02.08.2016 20:02, Christian Heimes wrote: > On 2016-07-19 17:03, Martin Basti wrote: >> >> On 12.07.2016 16:45, Christian Heimes wrote: >>> Custodia's server.keys file contain the private RSA keys for encrypting >>> and signing Custodia messages. The file was created with permission 644 >>> and is only secured by permission 700 of the directory >>> /etc/ipa/custodia. The installer and upgrader ensure that the file >>> has 600. >>> >>> The server.keys file and all keys are now removed when during >>> uninstallation of a server, too. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1353936 >>> https://fedorahosted.org/freeipa/ticket/6015 >>> https://fedorahosted.org/freeipa/ticket/6056 >>> >>> >> NACK >> >> ipa-server-install --uninstall doesn't work > I fixed it by splitting up uninstallation into two parts: > > 1) the server_del plugin takes care of the LDAP entries > 2) CustodiaInstance.uninstall() removes the local key file > Hello, 1) Is expected that after removing replica, ipa server-del vm-012.abc.idm.lab.eng.brq.redhat.com, I have these entries in LDAP on master (vm-058-107)? # sig/vm-012.abc.idm.lab.eng.brq.redhat.com, custodia, ipa, etc, abc.idm.lab.en g.brq.redhat.com dn: cn=sig/vm-012.abc.idm.lab.eng.brq.redhat.com,cn=custodia,cn=ipa,cn=etc,dc= abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com objectClass: nsContainer objectClass: ipaKeyPolicy objectClass: ipaPublicKeyObject objectClass: groupOfPrincipals objectClass: top cn: sig/vm-012.abc.idm.lab.eng.brq.redhat.com ipaKeyUsage: digitalSignature memberPrincipal: host/vm-012.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BR Q.REDHAT.COM ipaPublicKey:: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqV4NGWu8224ar3IdwlD cOpNBjcQKY0gznMuAjlikHKxnpfzmGCf/GYxfealet64ek3RE3oLmYhITqX3NkLKw51KhuwGcEw31 hBa6YB/6uzx3tr/ruO++vk+U7Myz4eFzp7+Zryjk7ohVb3w/XhBcVbC+d9qyKGzM0OUaQgGOjy7eq 3tiI+VugfyawvAvItCwyo56R8fO1jS1uKA+NDz5ltIymE9sySpVWfTMhCDUEjy9iEMiPixtiyVbHd g8A80H7W4fe7mTcqkKPD6sfYr2QwKh4pF7wU+RHfXsoXIu5gYNPgxdsHd/1p914EQ9U6RYTFsSEzk DR8V2H1rJ0AiVPQIDAQAB # enc/vm-012.abc.idm.lab.eng.brq.redhat.com, custodia, ipa, etc, abc.idm.lab.en g.brq.redhat.com dn: cn=enc/vm-012.abc.idm.lab.eng.brq.redhat.com,cn=custodia,cn=ipa,cn=etc,dc= abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com objectClass: nsContainer objectClass: ipaKeyPolicy objectClass: ipaPublicKeyObject objectClass: groupOfPrincipals objectClass: top cn: enc/vm-012.abc.idm.lab.eng.brq.redhat.com ipaKeyUsage: dataEncipherment memberPrincipal: host/vm-012.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BR Q.REDHAT.COM ipaPublicKey:: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5vdu9LLl7Pa+cN+ivNO eOon1BOI3bbBzYAu8+l1ch8iepKJrom4O5yYT7qhz5aYgq4Pd2kuxuvcuf3OlGTizuKlqRELbVnG0 ogWN/YAqPExS6L2hEHcyIZTiOQk19jT/ynEqayjH/OM499aE1H3vc7FD30Cy9wBQNUzYuY8pWpaWd Jj8nbvEKLX7JYPSx5/3Bqx+tqK5ApAGutJ6lF3+9acuG6ADVwUY3hAqXcqu4Oy463LKIhdatqMv2r j0FEFHJYPG2GTOIhFF8jee2Q7iidgPNdfbvKCYbnAkXtT73hxJWTckoupGHpUo+5b/wl8pI1Lxhyz TIp7oPmFWMG/q1QIDAQAB Also see them on replica as well (which was removed from topology) I did not find any errors in http log 2) I tried hard, but I cannot see relation between https://fedorahosted.org/freeipa/ticket/6015 and https://fedorahosted.org/freeipa/ticket/6056 IMO it should be separated into two patches, to make easier backports, patching and make life easier in future with git blame There should not be a BZ, only upstream tickets in commit 3) IMO ti should be 'Removing' not 'Remove', I'm not native speaker, but it looks more consistent with the rest of log entries INFO Remove Custodia keys 4) the same for root_logger.info("Secure server.keys mode"), IMHO it should be 'Securing' 5) What is the purpose of remove_server_keys() in KEM.py . I see usage only in manual testing. Can it be reused in server.py ? Because it looks like duplicated code for me, but correct me if I'm wrong. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Aug 3 17:23:40 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 3 Aug 2016 19:23:40 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: <0b7f3090-5d9d-7044-2520-93361117c1c1@redhat.com> References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> <9751cf00-78b4-0dfd-4c70-7a04cb930215@redhat.com> <5e7f167e-b5d3-fd5a-1ec0-599df9ce0b31@redhat.com> <0b7f3090-5d9d-7044-2520-93361117c1c1@redhat.com> Message-ID: On 03.08.2016 13:42, Christian Heimes wrote: > On 2016-07-07 14:54, Martin Basti wrote: >> Patch needs changes in ipa-4-3 branch > Here are patches for master and ipa-4-3 branch. I have rebased both > patches to head. > > Christian > ACK master: * 1de92b13266b7ac748581f963d8fe7bdb87d1563 RedHatCAService should wait for local Dogtag instance ipa-4-3: * 16491d7949d4a0a088bbadf69a80866f491fd5b0 RedHatCAService should wait for local Dogtag instance From mbasti at redhat.com Wed Aug 3 17:39:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 3 Aug 2016 19:39:07 +0200 Subject: [Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install In-Reply-To: References: <4975c47e-ce78-9e73-7849-f0d77909db7f@redhat.com> <2337c1e9-8d5a-8329-4e11-426b7f231839@redhat.com> <235931cd-67d6-6266-06cb-bd294395e1f3@redhat.com> <5af4f271-4add-ea82-2179-c9357fdac3d9@redhat.com> Message-ID: <1095646d-d146-3462-4158-11be0cc675f1@redhat.com> On 03.08.2016 18:10, Petr Vobornik wrote: > On 07/13/2016 12:36 PM, Stanislav Laznicka wrote: >> On 07/13/2016 09:51 AM, Petr Vobornik wrote: >>> On 07/13/2016 08:26 AM, Stanislav Laznicka wrote: >>>> On 07/12/2016 08:44 AM, Stanislav Laznicka wrote: >>>>> On 07/11/2016 04:27 PM, Petr Vobornik wrote: >>>>>> On 07/11/2016 01:23 PM, Stanislav Laznicka wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/6046 >>>>>>> >>>>>>> >>>>>>> >>>>>> Isn't the bug about something else? >>>>>> >>>>>> The issue was that ipa-replica-install doesn't have --force-ntpd >>>>>> option. >>>>>> It is an option of ipa-client-install which is run from replica >>>>>> installer. >>>>>> >>>>>> The unattended mode is unrelated. >>>>> My understanding is that the bug says that '--force-ntpd' option >>>>> should not be shown when ipa-client-install is run during replica >>>>> installation. >>>>> >>>>> During replica installation, the ipa-client-install script is run with >>>>> the '--unattended' flag in the 'ensure_enrolled()' function. Being a >>>>> separate script, there's not many options on how to pass the >>>>> information not to show the message to ipa-client-install. Using the >>>>> already used flag to get rid of the message seemed easiest to me. >>>>> Introducing a new 'hidden' flag (like '--from-replica'), on the other >>>>> hand, seems a bit harsh. >>>>> >>>> Just to throw it out there - it's possible that the '--force-join' >>>> client option would also appear as a hint from the client install script >>>> (during replica installation). Should this also be muted somehow? To me, >>>> it seems reasonable to rather add it as an argument to >>>> ipa-replica-install to pass it to the client install script. >>>> >>> IMO client installation initiated from replica needs to have a special >>> option(hidden in help) similar to --on-server (or what's its name). E.g. >>> the name can be --replica-install. Maybe --on-server can be used but it >>> may have other implication which might not be valid for this use case. >>> >>> Anything else are just workarounds. Imagine that admin runs >>> ipa-client-install with --unattended or --force-join. He would then not >>> get the message as now. > Reviving thread to get other opinion. > >> The --on-master option won't do here as it seems that the client would >> require some IPA pre-configuration for successful install. A new option >> will have to be created, then. > I'm for new "hidden" option. I'm against any hidden options, this should be made correctly by modularization/fixing of client install, to be able call it from python not as external process Just from top of my head, can we just use option --no-ntp with client install in replica installer? Server NTP should not depend on client ntp config. I'm just afraid that we may get kerberos time issue during client install if client time does not match server time. Or second approach, always call client install from replica with --force-ntpd, unless there is --no-ntp used for replica, then call ipa-client-install with --no-ntp But it needs investigation. Martin^2 > >> As I was trying to point out, the situation about --force-join is a bit >> different. The option again would be shown and is not available in >> ipa-replica-install. I think it should be available to allow direct >> replica installation even when previous installation failed/left some >> mess on the master (ofc the user could run `ipa-replica-manage del >> --cleanup` on the master instead). >> > That could work but imho is out of scope of this ticket. From mbasti at redhat.com Wed Aug 3 18:21:58 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 3 Aug 2016 20:21:58 +0200 Subject: [Freeipa-devel] [PATCH 0032] Secure permission and cleanup Custodia server.keys In-Reply-To: <72042d4c-cd89-b30c-dc35-679360d96e0c@redhat.com> References: <5159a7b0-7942-3a8b-ff16-94925488f303@redhat.com> <72042d4c-cd89-b30c-dc35-679360d96e0c@redhat.com> Message-ID: On 03.08.2016 19:18, Martin Basti wrote: > > > > On 02.08.2016 20:02, Christian Heimes wrote: >> On 2016-07-19 17:03, Martin Basti wrote: >>> On 12.07.2016 16:45, Christian Heimes wrote: >>>> Custodia's server.keys file contain the private RSA keys for encrypting >>>> and signing Custodia messages. The file was created with permission 644 >>>> and is only secured by permission 700 of the directory >>>> /etc/ipa/custodia. The installer and upgrader ensure that the file >>>> has 600. >>>> >>>> The server.keys file and all keys are now removed when during >>>> uninstallation of a server, too. >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1353936 >>>> https://fedorahosted.org/freeipa/ticket/6015 >>>> https://fedorahosted.org/freeipa/ticket/6056 >>>> >>>> >>> NACK >>> >>> ipa-server-install --uninstall doesn't work >> I fixed it by splitting up uninstallation into two parts: >> >> 1) the server_del plugin takes care of the LDAP entries >> 2) CustodiaInstance.uninstall() removes the local key file >> > > Hello, > > 1) > Is expected that after removing replica, ipa server-del > vm-012.abc.idm.lab.eng.brq.redhat.com, I have these entries in LDAP on > master (vm-058-107)? > > # sig/vm-012.abc.idm.lab.eng.brq.redhat.com, custodia, ipa, etc, > abc.idm.lab.en > g.brq.redhat.com > dn: > cn=sig/vm-012.abc.idm.lab.eng.brq.redhat.com,cn=custodia,cn=ipa,cn=etc,dc= > abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > objectClass: nsContainer > objectClass: ipaKeyPolicy > objectClass: ipaPublicKeyObject > objectClass: groupOfPrincipals > objectClass: top > cn: sig/vm-012.abc.idm.lab.eng.brq.redhat.com > ipaKeyUsage: digitalSignature > memberPrincipal: > host/vm-012.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BR > Q.REDHAT.COM > ipaPublicKey:: > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqV4NGWu8224ar3IdwlD > cOpNBjcQKY0gznMuAjlikHKxnpfzmGCf/GYxfealet64ek3RE3oLmYhITqX3NkLKw51KhuwGcEw31 > hBa6YB/6uzx3tr/ruO++vk+U7Myz4eFzp7+Zryjk7ohVb3w/XhBcVbC+d9qyKGzM0OUaQgGOjy7eq > 3tiI+VugfyawvAvItCwyo56R8fO1jS1uKA+NDz5ltIymE9sySpVWfTMhCDUEjy9iEMiPixtiyVbHd > g8A80H7W4fe7mTcqkKPD6sfYr2QwKh4pF7wU+RHfXsoXIu5gYNPgxdsHd/1p914EQ9U6RYTFsSEzk > DR8V2H1rJ0AiVPQIDAQAB > > # enc/vm-012.abc.idm.lab.eng.brq.redhat.com, custodia, ipa, etc, > abc.idm.lab.en > g.brq.redhat.com > dn: > cn=enc/vm-012.abc.idm.lab.eng.brq.redhat.com,cn=custodia,cn=ipa,cn=etc,dc= > abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > objectClass: nsContainer > objectClass: ipaKeyPolicy > objectClass: ipaPublicKeyObject > objectClass: groupOfPrincipals > objectClass: top > cn: enc/vm-012.abc.idm.lab.eng.brq.redhat.com > ipaKeyUsage: dataEncipherment > memberPrincipal: > host/vm-012.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BR > Q.REDHAT.COM > ipaPublicKey:: > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5vdu9LLl7Pa+cN+ivNO > eOon1BOI3bbBzYAu8+l1ch8iepKJrom4O5yYT7qhz5aYgq4Pd2kuxuvcuf3OlGTizuKlqRELbVnG0 > ogWN/YAqPExS6L2hEHcyIZTiOQk19jT/ynEqayjH/OM499aE1H3vc7FD30Cy9wBQNUzYuY8pWpaWd > Jj8nbvEKLX7JYPSx5/3Bqx+tqK5ApAGutJ6lF3+9acuG6ADVwUY3hAqXcqu4Oy463LKIhdatqMv2r > j0FEFHJYPG2GTOIhFF8jee2Q7iidgPNdfbvKCYbnAkXtT73hxJWTckoupGHpUo+5b/wl8pI1Lxhyz > TIp7oPmFWMG/q1QIDAQAB > > Also see them on replica as well (which was removed from topology) > I did not find any errors in http log > > 2) > I tried hard, but I cannot see relation between > https://fedorahosted.org/freeipa/ticket/6015 and > https://fedorahosted.org/freeipa/ticket/6056 > IMO it should be separated into two patches, to make easier backports, > patching and make life easier in future with git blame > > There should not be a BZ, only upstream tickets in commit > > 3) > IMO ti should be 'Removing' not 'Remove', I'm not native speaker, but > it looks more consistent with the rest of log entries > > INFO Remove Custodia keys > > 4) > the same for > root_logger.info("Secure server.keys mode"), IMHO it should be 'Securing' > > 5) > What is the purpose of remove_server_keys() in KEM.py . I see usage > only in manual testing. Can it be reused in server.py ? Because it > looks like duplicated code for me, but correct me if I'm wrong. > > Martin^2 > > > > > I received this when I tried to uninstall already uninstalled replica (calling ipa-replica-install -U --uninstall twice) 2016-08-03T17:45:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-08-03T17:45:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-08-03T17:45:13Z INFO Remove Custodia keys 2016-08-03T17:45:13Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 91, in _handle_exception super(Continuous, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 71, in _uninstall for nothing in self._uninstaller(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 1375, in main uninstall(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 266, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 1076, in uninstall custodiainstance.CustodiaInstance().uninstall() File "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line 88, in uninstall self.__remove_keys() File "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line 72, in __remove_keys keystore = IPAKEMKeys({'server_keys': self.server_keys}) File "/usr/lib/python2.7/site-packages/ipapython/secrets/kem.py", line 193, in __init__ self.host = conf.get('global', 'host') File "/usr/lib64/python2.7/ConfigParser.py", line 607, in get raise NoSectionError(section) NoSectionError: No section: 'global' -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Aug 3 18:44:05 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 3 Aug 2016 20:44:05 +0200 Subject: [Freeipa-devel] [PATCH 0153] Fix ipa-replica-prepare's error message about missing local CA instanc In-Reply-To: <04a436fd-bc8b-e57b-d3dd-320b26fb0d68@redhat.com> References: <04a436fd-bc8b-e57b-d3dd-320b26fb0d68@redhat.com> Message-ID: On 01.08.2016 17:38, Petr Spacek wrote: > Hello, > > Fix ipa-replica-prepare's error message about missing local CA instance > > ipa-replica-prepare must be run on a replica with CA or all the certs > needs to be provided (for CA-less case). > > The old messages were utterly confusing because they mixed errors about > missing certs and missing local CA instance into one text. > > https://fedorahosted.org/freeipa/ticket/6134 > > > ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Wed Aug 3 20:46:44 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 3 Aug 2016 22:46:44 +0200 Subject: [Freeipa-devel] Broken IPA installations on F24 In-Reply-To: <319d85d8-8d1d-6221-bc09-7ee81328abc7@redhat.com> References: <319d85d8-8d1d-6221-bc09-7ee81328abc7@redhat.com> Message-ID: <20160803204644.GA11112@10.4.128.1> On (03/08/16 14:17), Martin Basti wrote: >Hello all, > > >update resteasy-*-3.0.17 from updates-testing prevents IPA (PKI CA) to be >installed on f24, > >ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA >instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpEQulGP' returned >non-zero exit status 1 >ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation >logs and the following files/directories for more information: >ipa.ipaserver.install.cainstance.CAInstance: CRITICAL /var/log/pki/pki-tomcat > [error] RuntimeError: CA configuration failed. >ipa.ipapython.install.cli.install_tool(Server): ERROR CA configuration >failed. >ipa.ipapython.install.cli.install_tool(Server): ERROR The >ipa-server-install command failed. See /var/log/ipaserver-install.log for >more information > >Workaround: > ># dnf downgrade resteasy-atom-provider resteasy-client resteasy-core >resteasy-jackson-provider resteasy-jaxb-provider --allowerasing > Fraser, Is a bug in resteasy or dogtag? LS From blipton at redhat.com Wed Aug 3 20:56:59 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 3 Aug 2016 16:56:59 -0400 Subject: [Freeipa-devel] [PATCH 0153] Fix ipa-replica-prepare's error message about missing local CA instanc In-Reply-To: <04a436fd-bc8b-e57b-d3dd-320b26fb0d68@redhat.com> References: <04a436fd-bc8b-e57b-d3dd-320b26fb0d68@redhat.com> Message-ID: On 08/01/2016 11:38 AM, Petr Spacek wrote: > Hello, > > Fix ipa-replica-prepare's error message about missing local CA instance > > ipa-replica-prepare must be run on a replica with CA or all the certs > needs to be provided (for CA-less case). > > The old messages were utterly confusing because they mixed errors about > missing certs and missing local CA instance into one text. > > https://fedorahosted.org/freeipa/ticket/6134 > > > The error message in the patch says "must be ran" instead of "must be run". -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Thu Aug 4 03:40:56 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 4 Aug 2016 13:40:56 +1000 Subject: [Freeipa-devel] Broken IPA installations on F24 In-Reply-To: <319d85d8-8d1d-6221-bc09-7ee81328abc7@redhat.com> References: <319d85d8-8d1d-6221-bc09-7ee81328abc7@redhat.com> Message-ID: <20160804034055.GO10771@dhcp-40-8.bne.redhat.com> On Wed, Aug 03, 2016 at 02:17:30PM +0200, Martin Basti wrote: > Hello all, > > > update resteasy-*-3.0.17 from updates-testing prevents IPA (PKI CA) to be > installed on f24, > > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA > instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpEQulGP' returned > non-zero exit status 1 > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation > logs and the following files/directories for more information: > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL > /var/log/pki/pki-tomcat > [error] RuntimeError: CA configuration failed. > ipa.ipapython.install.cli.install_tool(Server): ERROR CA configuration > failed. > ipa.ipapython.install.cli.install_tool(Server): ERROR The > ipa-server-install command failed. See /var/log/ipaserver-install.log for > more information > > Workaround: > > # dnf downgrade resteasy-atom-provider resteasy-client resteasy-core > resteasy-jackson-provider resteasy-jaxb-provider --allowerasing > > > Please provide negative karma, we must prevent this to get into updates, it > will break IPA 4.3 on F24: > > https://bodhi.fedoraproject.org/updates/FEDORA-2016-d80872c309 > > > Regards > > Martin^2 > I think this is issue https://fedorahosted.org/pki/ticket/2403 which has been fixed by Endi in pki master. We plan to release v10.3.5 next week. Cheers, Fraser From jcholast at redhat.com Thu Aug 4 05:34:58 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 4 Aug 2016 07:34:58 +0200 Subject: [Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install In-Reply-To: <1095646d-d146-3462-4158-11be0cc675f1@redhat.com> References: <4975c47e-ce78-9e73-7849-f0d77909db7f@redhat.com> <2337c1e9-8d5a-8329-4e11-426b7f231839@redhat.com> <235931cd-67d6-6266-06cb-bd294395e1f3@redhat.com> <5af4f271-4add-ea82-2179-c9357fdac3d9@redhat.com> <1095646d-d146-3462-4158-11be0cc675f1@redhat.com> Message-ID: On 3.8.2016 19:39, Martin Basti wrote: > > > On 03.08.2016 18:10, Petr Vobornik wrote: >> On 07/13/2016 12:36 PM, Stanislav Laznicka wrote: >>> On 07/13/2016 09:51 AM, Petr Vobornik wrote: >>>> On 07/13/2016 08:26 AM, Stanislav Laznicka wrote: >>>>> On 07/12/2016 08:44 AM, Stanislav Laznicka wrote: >>>>>> On 07/11/2016 04:27 PM, Petr Vobornik wrote: >>>>>>> On 07/11/2016 01:23 PM, Stanislav Laznicka wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/6046 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Isn't the bug about something else? >>>>>>> >>>>>>> The issue was that ipa-replica-install doesn't have --force-ntpd >>>>>>> option. >>>>>>> It is an option of ipa-client-install which is run from replica >>>>>>> installer. >>>>>>> >>>>>>> The unattended mode is unrelated. >>>>>> My understanding is that the bug says that '--force-ntpd' option >>>>>> should not be shown when ipa-client-install is run during replica >>>>>> installation. >>>>>> >>>>>> During replica installation, the ipa-client-install script is run >>>>>> with >>>>>> the '--unattended' flag in the 'ensure_enrolled()' function. Being a >>>>>> separate script, there's not many options on how to pass the >>>>>> information not to show the message to ipa-client-install. Using the >>>>>> already used flag to get rid of the message seemed easiest to me. >>>>>> Introducing a new 'hidden' flag (like '--from-replica'), on the other >>>>>> hand, seems a bit harsh. >>>>>> >>>>> Just to throw it out there - it's possible that the '--force-join' >>>>> client option would also appear as a hint from the client install >>>>> script >>>>> (during replica installation). Should this also be muted somehow? >>>>> To me, >>>>> it seems reasonable to rather add it as an argument to >>>>> ipa-replica-install to pass it to the client install script. >>>>> >>>> IMO client installation initiated from replica needs to have a special >>>> option(hidden in help) similar to --on-server (or what's its name). >>>> E.g. >>>> the name can be --replica-install. Maybe --on-server can be used but it >>>> may have other implication which might not be valid for this use case. >>>> >>>> Anything else are just workarounds. Imagine that admin runs >>>> ipa-client-install with --unattended or --force-join. He would then not >>>> get the message as now. >> Reviving thread to get other opinion. >> >>> The --on-master option won't do here as it seems that the client would >>> require some IPA pre-configuration for successful install. A new option >>> will have to be created, then. >> I'm for new "hidden" option. > > I'm against any hidden options, this should be made correctly by > modularization/fixing of client install, to be able call it from python > not as external process +1, but this is non-trivial and definitely not material for 4.4.1. For 4.4.1 the hidden option should be OK. > > Just from top of my head, can we just use option --no-ntp with client > install in replica installer? Server NTP should not depend on client ntp > config. > I'm just afraid that we may get kerberos time issue during client > install if client time does not match server time. > > Or second approach, always call client install from replica with > --force-ntpd, unless there is --no-ntp used for replica, then call > ipa-client-install with --no-ntp > > But it needs investigation. CCing David as he knows everything NTP-related. > > Martin^2 > >> >>> As I was trying to point out, the situation about --force-join is a bit >>> different. The option again would be shown and is not available in >>> ipa-replica-install. I think it should be available to allow direct >>> replica installation even when previous installation failed/left some >>> mess on the master (ofc the user could run `ipa-replica-manage del >>> --cleanup` on the master instead). >>> >> That could work but imho is out of scope of this ticket. > -- Jan Cholasta From ofayans at redhat.com Thu Aug 4 07:25:14 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 4 Aug 2016 09:25:14 +0200 Subject: [Freeipa-devel] [Tests][patch-0066] Fixed incorrect domainlevel determination in integration tests Message-ID: <57A2EDDA.6040002@redhat.com> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0055-Fixed-incorrect-domainlevel-determination-in-tests.patch Type: text/x-patch Size: 990 bytes Desc: not available URL: From ldoudova at redhat.com Thu Aug 4 08:12:13 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 4 Aug 2016 10:12:13 +0200 Subject: [Freeipa-devel] [PATCH 0196] baseldap: Fix MidairCollision instantiation during entry modification In-Reply-To: <20160726152219.u67pdvfxg4mwkogc@redhat.com> References: <20160726152219.u67pdvfxg4mwkogc@redhat.com> Message-ID: <228dc232-83b6-9e1f-ad4c-cfbbd4a644c1@redhat.com> On 07/26/2016 05:22 PM, Alexander Bokovoy wrote: > On Tue, 26 Jul 2016, Martin Babinsky wrote: >> Fix for https://fedorahosted.org/freeipa/ticket/6097 >> >> Since this issue was found during investigation of other ticket[1], >> you can test it by performing steps to reproduce #6041, but instead >> of internal error you should see the MidairCollision raised as public >> error with the right error message. >> >> [1] https://fedorahosted.org/freeipa/ticket/6041 > I have a preliminary patch for slapi-nis to fix 6041 (attached). Bump for review on this. > > As for this fix -- ACK. > >> >> -- >> Martin^3 Babinsky > >> From 8f0d6dab08f61fe2fd1ad64a63f7ab91fc5227d4 Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Mon, 25 Jul 2016 14:05:08 +0200 >> Subject: [PATCH] baseldap: Fix MidairCollision instantiation during >> entry >> modification >> >> https://fedorahosted.org/freeipa/ticket/6097 >> --- >> ipaserver/plugins/baseldap.py | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/ipaserver/plugins/baseldap.py >> b/ipaserver/plugins/baseldap.py >> index >> 6107e43a6ee17d9b9a63d9dc109664d8b232069f..f7844e3e7c59c259b9c8367d135b2dbefc3f0016 >> 100644 >> --- a/ipaserver/plugins/baseldap.py >> +++ b/ipaserver/plugins/baseldap.py >> @@ -1466,7 +1466,7 @@ class LDAPUpdate(LDAPQuery, crud.Update): >> entry_attrs.dn, attrs_list) >> except errors.NotFound: >> raise errors.MidairCollision( >> - format=_('the entry was deleted while being modified') >> + message=_('the entry was deleted while being modified') >> ) >> >> self.obj.get_indirect_members(entry_attrs, attrs_list) >> @@ -2344,7 +2344,7 @@ class BaseLDAPModAttribute(LDAPQuery): >> entry_attrs.dn, attrs_list) >> except errors.NotFound: >> raise errors.MidairCollision( >> - format=_('the entry was deleted while being modified') >> + message=_('the entry was deleted while being modified') >> ) >> >> for callback in self.get_callbacks('post'): >> -- >> 2.7.4 >> > >> -- >> Manage your subscription for the Freeipa-devel mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Aug 4 08:46:25 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 4 Aug 2016 10:46:25 +0200 Subject: [Freeipa-devel] [PATCH 683] install: fix external CA cert validation Message-ID: Hi, the attached patch fixes . Pushed under the one-liner rule to: master: a42b456b91cb345e977c6f0febf5c30f15a954d3 ipa-4-3: 44401d26c29e35d38bc94a7a87b9f2dd205e0643 Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-683-install-fix-external-CA-cert-validation.patch Type: text/x-patch Size: 1129 bytes Desc: not available URL: From ofayans at redhat.com Thu Aug 4 11:38:58 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 4 Aug 2016 13:38:58 +0200 Subject: [Freeipa-devel] [Test][patch-0056] Fixed incorrect returncode assert in test Message-ID: <57A32952.8070209@redhat.com> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0056-Fixed-incorrect-return-code-assert.patch Type: text/x-patch Size: 1482 bytes Desc: not available URL: From jcholast at redhat.com Thu Aug 4 12:20:47 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 4 Aug 2016 14:20:47 +0200 Subject: [Freeipa-devel] [PATCH 684] vault: add missing salt option to vault_mod Message-ID: <7b486913-d350-a969-b3c0-c4366db05b20@redhat.com> Hi, the attached patch fixes . Pushed under the one-liner rule to master: 1a73477e1561b0a2a66852575010a136edc014a6 Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-684-vault-add-missing-salt-option-to-vault_mod.patch Type: text/x-patch Size: 975 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 4 13:09:59 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 4 Aug 2016 15:09:59 +0200 Subject: [Freeipa-devel] [PATCH] 0096 caacl: fix regression in rule instantiation In-Reply-To: <20160729042103.GK10771@dhcp-40-8.bne.redhat.com> References: <20160728013118.GA10771@dhcp-40-8.bne.redhat.com> <3131b303-a873-1575-9488-f764c7dd96be@redhat.com> <20160729042103.GK10771@dhcp-40-8.bne.redhat.com> Message-ID: <93487384-dec1-13f2-8e0b-e94dc0baf20a@redhat.com> On 29.07.2016 06:21, Fraser Tweedale wrote: > On Thu, Jul 28, 2016 at 09:56:30AM +0200, Martin Babinsky wrote: >> On 07/28/2016 03:31 AM, Fraser Tweedale wrote: >>> The attached patch fixes a kerberos.Principal-related regression. >>> >>> Thanks, >>> Fraser >>> >> Hi Fraser, >> >> The ticket you linked in the commit message points to a closed milestone. >> You have to open a new ticket which needs to be triaged. Sorry, those are >> the processes. >> > Filed ticket: https://fedorahosted.org/freeipa/ticket/6146 > Updated patch attached (rebase and update commit message only). > > Thanks, > Fraser > > ACK, works for me -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Aug 4 13:12:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 4 Aug 2016 15:12:45 +0200 Subject: [Freeipa-devel] [Test][patch-0056] Fixed incorrect returncode assert in test In-Reply-To: <57A32952.8070209@redhat.com> References: <57A32952.8070209@redhat.com> Message-ID: On 04.08.2016 13:38, Oleg Fayans wrote: > > > Pushed to master: 2df047b8c51098bae9224b88dbdf03e5f9504f21 ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Thu Aug 4 14:19:30 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 4 Aug 2016 16:19:30 +0200 Subject: [Freeipa-devel] [PATCH] 0013 Fix ipa hbactest output In-Reply-To: <280c85d0-648f-4ffd-e4ae-993f8b71578f@redhat.com> References: <280c85d0-648f-4ffd-e4ae-993f8b71578f@redhat.com> Message-ID: <8000c6a1-0c25-e96a-2921-5845bb5b48c8@redhat.com> On 08/03/2016 05:49 PM, Martin Basti wrote: > > > On 02.08.2016 13:22, Florence Blanc-Renaud wrote: >> Hi, >> >> please find attached a patch related to 'ipa hbactest' producing a >> Traceback. >> >> https://fedorahosted.org/freeipa/ticket/6157 >> >> Flo. >> >> > Hello Flo, > > > 1) > can you please move that check, right bellow the for? > > for o in self.output: > + if o == 'value': > + continue > > It is peformance improvements :) We should not waste time with getting > values from dict if we will not use them > > 2) > elif isinstance(result, (unicode, bool)): > if o == 'summary': > textui.print_summary(result) > else: > textui.print_indented(result) > > Here you should remove the 'bool' from isinstance or update > print_indented to allow work with boolean (I prefer the first one). > Because with any other bool value it will fail again. > > Thanks, > Martin^2 Hi Martin, thanks for the review. Please find an updated patch with your comments. Flo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-0013-2-Fix-ipa-hbactest-output.patch Type: text/x-patch Size: 1771 bytes Desc: not available URL: From dkupka at redhat.com Thu Aug 4 14:32:39 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 4 Aug 2016 16:32:39 +0200 Subject: [Freeipa-devel] [PATCH 0112-7] Speeding up cli help In-Reply-To: <29310e45-fc18-52fc-1686-651bb42480c9@redhat.com> References: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> <01ff40a4-b964-4f78-33dd-f1c92c490fdd@redhat.com> <29310e45-fc18-52fc-1686-651bb42480c9@redhat.com> Message-ID: <547fcaaa-c86c-f547-c049-2de82df78de8@redhat.com> On 03/08/16 16:33, Jan Cholasta wrote: > On 3.8.2016 16:23, David Kupka wrote: >> On 21/07/16 10:12, Jan Cholasta wrote: >>> Hi, >>> >>> On 20.7.2016 14:32, David Kupka wrote: >>>> On 15/07/16 12:53, David Kupka wrote: >>>>> Hello! >>>>> >>>>> After Honza introduced thin client that builds plugins and commands >>>>> dynamically from schema client became much slower. This is only >>>>> logical, >>>>> instead of importing a module client now must fetch the schema from >>>>> server, parse it and instantiate the commands using the data. >>>>> >>>>> First step to speed it up was addition of schema cache to client. That >>>>> removed the RTT and download time of fetching schema every time. >>>>> >>>>> Now the most time consuming task became displaying help for lists of >>>>> topics and command and displaying individual topics. This is simply >>>>> because of the need to instantiate all the commands to find the >>>>> relations between topics and commands. >>>>> >>>>> All the necessary bits for server commands and topics are already in >>>>> the >>>>> schema cache so we can skip this part and generate help from it, >>>>> right? >>>>> Not so fast! >>>>> >>>>> There are client plugins with commands and topics. So we can generate >>>>> basic bits (list of all topics, list of all commands, list of commands >>>>> for each topic) from schema and store it in cache. Then we need to go >>>>> through all client plugins and get similar bits for client plugins. >>>>> Then >>>>> we can merge and print. >>>>> >>>>> Still the client response is not as fast as before and I this it even >>>>> can't be. Also first time you display particular topic or list takes >>>>> longer because it must be freshly generated and stored in cache for >>>>> next >>>>> use. And this is what the attached patches do. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6048 >>>> >>>> Reimplemented so there is no need to distinguish client plugins and >>>> remote plugins. >>>> The main idea of this approach is to avoid creating instances of the >>>> commands just to get the information about topic, name and summary >>>> needed for displaying help. Instead class properties are used to access >>>> the information directly in schema. >>> >>> Patch 0112: >>> >>> I think this would better be done in Schema.read_namespace_member, >>> because Schema is where all the state is. >>> >>> (BTW does _SchemaNameSpace.__getitem__ raise KeyError for non-existent >>> keys? It looks like it doesn't.) >>> >>> >>> Patch 0113: >>> >>> How about setting _schema_cached to False in Schema.__init__() rather >>> that getattr()-ing it in _ensure_cached()? >>> >>> >>> Patch 0116: >>> >>> ClientCommand.doc should be a class property as well, otherwise .summary >>> won't work on it correctly. >>> >>> _SchemaCommand.doc should not be a property, as it's not needed for >>> .summary to work on it correctly. >>> >>> >>> Otherwise works fine for me. >>> >>> Honza >>> >> >> Updated patches attached. > > Thanks, ACK. > > Pushed to master: 229e2a1ed9ea9877cb5e879fadd99f9040f77c96 > I've made and reviewer overlooked some errors. Attached patches fix them. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0119.0-schema-cache-Do-not-reset-ServerInfo-dirty-flag.patch Type: text/x-patch Size: 1131 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0120.0-schema-cache-Write-format-information-in-cache.patch Type: text/x-patch Size: 1029 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0121.0-Access-data-for-help-separately.patch Type: text/x-patch Size: 4102 bytes Desc: not available URL: From Peter.Marx at knorr-bremse.com Thu Aug 4 14:51:33 2016 From: Peter.Marx at knorr-bremse.com (Marx, Peter) Date: Thu, 4 Aug 2016 14:51:33 +0000 Subject: [Freeipa-devel] certmonger proxy configuration not possible ? In-Reply-To: <57A1F6EA.9080901@redhat.com> References: <2C720BBFE8885346B9A4377911BABE7886889266@MUCS72046.corp.knorr-bremse.com> <57A1F6EA.9080901@redhat.com> Message-ID: <2C720BBFE8885346B9A4377911BABE788688ADD9@MUCS72046.corp.knorr-bremse.com> I tried it and found out it can't work this way - when issuing a CSR with getcert, the parameters of this request are normally handed over by getcert to the scep-submit helper. I see no way to intercept these parameters and pass them to the proxy-shellscript. Only the -u paramter is known beforehand, as it is configured in the ca description file or in the proxy shellscript itself. Peter -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, August 03, 2016 3:52 PM To: Marx, Peter; 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certmonger proxy configuration not possible ? Marx, Peter wrote: > Hi, > > i have to access an external PKI server with SCEP protocol through our > corporate proxy. On command line I can set the proxy and trigger a > CSR with the scep-submit helper successfully. What are you setting, environment variables I assume? > But same operation with getcert fails, as there is no proxy > configuration possibility in e.g. certmonger.conf. > > How can I work around this ? A quick kludge might be to replace scep-submit with a shell script that exports the proxy config and then calls the real scep-submit. A perhaps better and more supportable idea would be to add a CA pointing to this new helper, something like: getcert add-ca -c exampleSCEPca -e \ "/usr/libexec/certmonger/scep-submit-proxy -u http://ca.example.com/cgi-bin/pkiclient.exe" So scep-submit-proxy would setup the environment and call scep-submit. rob > > Peter > > > > Knorr-Bremse IT-Services GmbH > Sitz: M?nchen > Gesch?ftsf?hrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald > Schneider Registergericht M?nchen, HR B 167 268 > > This transmission is intended solely for the addressee and contains > confidential information. > If you are not the intended recipient, please immediately inform the > sender and delete the message and any attachments from your system. > Furthermore, please do not copy the message or disclose the contents > to anyone unless agreed otherwise. To the extent permitted by law we > shall in no way be liable for any damages, whatever their nature, > arising out of transmission failures, viruses, external influence, delays and the like. > > automechanika - 13.09.-17.09.2016 - Messe Frankfurt - Hall 3.0 - Stand G98 + E91 InnoTrans - 20.09.-23.09.2016 - Messe Berlin - Hall 1.2b - Stand 104 + 210 IAA - 22.09.-29.09.2016 - Messe Hannover - Hall 17 - Stand A30 + D131 Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. From mbasti at redhat.com Thu Aug 4 15:14:42 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 4 Aug 2016 17:14:42 +0200 Subject: [Freeipa-devel] [PATCH] 0013 Fix ipa hbactest output In-Reply-To: <8000c6a1-0c25-e96a-2921-5845bb5b48c8@redhat.com> References: <280c85d0-648f-4ffd-e4ae-993f8b71578f@redhat.com> <8000c6a1-0c25-e96a-2921-5845bb5b48c8@redhat.com> Message-ID: On 04.08.2016 16:19, Florence Blanc-Renaud wrote: > On 08/03/2016 05:49 PM, Martin Basti wrote: >> >> >> On 02.08.2016 13:22, Florence Blanc-Renaud wrote: >>> Hi, >>> >>> please find attached a patch related to 'ipa hbactest' producing a >>> Traceback. >>> >>> https://fedorahosted.org/freeipa/ticket/6157 >>> >>> Flo. >>> >>> >> Hello Flo, >> >> >> 1) >> can you please move that check, right bellow the for? >> >> for o in self.output: >> + if o == 'value': >> + continue >> >> It is peformance improvements :) We should not waste time with getting >> values from dict if we will not use them >> >> 2) >> elif isinstance(result, (unicode, bool)): >> if o == 'summary': >> textui.print_summary(result) >> else: >> textui.print_indented(result) >> >> Here you should remove the 'bool' from isinstance or update >> print_indented to allow work with boolean (I prefer the first one). >> Because with any other bool value it will fail again. >> >> Thanks, >> Martin^2 > Hi Martin, > > thanks for the review. Please find an updated patch with your comments. > Flo. Pushed to master: cad6a551d6558441ead4b2b71d0b906ecefbdb63 ACK From jpazdziora at redhat.com Thu Aug 4 15:27:55 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 4 Aug 2016 17:27:55 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <20160803072952.2ugaw5cfkd3fvntp@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> Message-ID: <20160804152755.GA4601@redhat.com> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: > > Got it. One thing I would correct, though, -- don't use kadmin.local, we > do support setting ok_as_delegate on the service principals via IPA CLI: > $ ipa service-mod --help |grep -A1 ok-as-delegate > --ok-as-delegate=BOOL > Client credentials may be delegated to the service I've tried ipa service-mod --ok-as-delegate=True HTTP/$(hostname) but that does not seem to have the same effect as modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test -- obtaining the delegated certificated fails. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From pspacek at redhat.com Thu Aug 4 15:35:17 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 4 Aug 2016 17:35:17 +0200 Subject: [Freeipa-devel] [PATCH 0153] Fix ipa-replica-prepare's error message about missing local CA instanc In-Reply-To: References: <04a436fd-bc8b-e57b-d3dd-320b26fb0d68@redhat.com> Message-ID: <770e0863-006c-9a01-05d8-9c20ed2fca18@redhat.com> On 3.8.2016 22:56, Ben Lipton wrote: > > On 08/01/2016 11:38 AM, Petr Spacek wrote: >> Hello, >> >> Fix ipa-replica-prepare's error message about missing local CA instance >> >> ipa-replica-prepare must be run on a replica with CA or all the certs >> needs to be provided (for CA-less case). >> >> The old messages were utterly confusing because they mixed errors about >> missing certs and missing local CA instance into one text. >> >> https://fedorahosted.org/freeipa/ticket/6134 >> >> >> > The error message in the patch says "must be ran" instead of "must be run". Thanks! Fixed patch is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0153-2-Fix-ipa-replica-prepare-s-error-message-about-missin.patch Type: text/x-patch Size: 2230 bytes Desc: not available URL: From abokovoy at redhat.com Thu Aug 4 15:49:20 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Aug 2016 18:49:20 +0300 Subject: [Freeipa-devel] External plugin integration Message-ID: <20160804154920.obmldg6bxip4ev7b@redhat.com> Hi! I've stumbled into an interesting problem. Suppose, I have a plugin that adds schema and a subtree where entries it manages will be stored. This subtree will have ACIs applied based on the plugin permissions' configuration. Now, I put schema file in /usr/ipa/share, and updates file in /usr/share/ipa/updates, and also add plugin code to the ipaserver/plugins/ (let's say, rpm does it for me). Next, I want to install IPA server. The install will run through up to server upgrade phase which will fail because generation of ACIs will reference schema attributes/classes which aren't loaded to the dirsrv by installer. How to solve it? Installer uses hard-coded list of schema files and this is a third-party plugin, it needs to extend the list of active schema files. If we can define a place where third-party plugins could drop schema and we just load everything from there before processing updates, it would probably be enough. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Aug 4 16:01:47 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Aug 2016 19:01:47 +0300 Subject: [Freeipa-devel] certmonger proxy configuration not possible ? In-Reply-To: <2C720BBFE8885346B9A4377911BABE788688ADD9@MUCS72046.corp.knorr-bremse.com> References: <2C720BBFE8885346B9A4377911BABE7886889266@MUCS72046.corp.knorr-bremse.com> <57A1F6EA.9080901@redhat.com> <2C720BBFE8885346B9A4377911BABE788688ADD9@MUCS72046.corp.knorr-bremse.com> Message-ID: <20160804160147.2mq54tfooquehlvh@redhat.com> On Thu, 04 Aug 2016, Marx, Peter wrote: >I tried it and found out it can't work this way - when issuing a CSR >with getcert, the parameters of this request are normally handed over >by getcert to the scep-submit helper. I see no way to intercept these >parameters and pass them to the proxy-shellscript. Only the -u >paramter is known beforehand, as it is configured in the ca description >file or in the proxy shellscript itself. On systemd-enabled systems certmonger runs as a service. You can affect the environment of the service by adding files ending in .conf in /etc/systemd/system/certmonger.service.d/ See systemd.service and systemd.unit man pages. > >Peter > >-----Original Message----- >From: Rob Crittenden [mailto:rcritten at redhat.com] >Sent: Wednesday, August 03, 2016 3:52 PM >To: Marx, Peter; 'freeipa-devel at redhat.com' >Subject: Re: [Freeipa-devel] certmonger proxy configuration not possible ? > >Marx, Peter wrote: >> Hi, >> >> i have to access an external PKI server with SCEP protocol through our >> corporate proxy. On command line I can set the proxy and trigger a >> CSR with the scep-submit helper successfully. > >What are you setting, environment variables I assume? > >> But same operation with getcert fails, as there is no proxy >> configuration possibility in e.g. certmonger.conf. >> >> How can I work around this ? > >A quick kludge might be to replace scep-submit with a shell script that exports the proxy config and then calls the real scep-submit. > >A perhaps better and more supportable idea would be to add a CA pointing to this new helper, something like: > >getcert add-ca -c exampleSCEPca -e \ > "/usr/libexec/certmonger/scep-submit-proxy -u http://ca.example.com/cgi-bin/pkiclient.exe" > >So scep-submit-proxy would setup the environment and call scep-submit. > >rob > >> >> Peter >> >> >> >> Knorr-Bremse IT-Services GmbH >> Sitz: M?nchen >> Gesch?ftsf?hrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald >> Schneider Registergericht M?nchen, HR B 167 268 >> >> This transmission is intended solely for the addressee and contains >> confidential information. >> If you are not the intended recipient, please immediately inform the >> sender and delete the message and any attachments from your system. >> Furthermore, please do not copy the message or disclose the contents >> to anyone unless agreed otherwise. To the extent permitted by law we >> shall in no way be liable for any damages, whatever their nature, >> arising out of transmission failures, viruses, external influence, delays and the like. >> >> > > >automechanika - 13.09.-17.09.2016 - Messe Frankfurt - Hall 3.0 - Stand G98 + E91 >InnoTrans - 20.09.-23.09.2016 - Messe Berlin - Hall 1.2b - Stand 104 + 210 >IAA - 22.09.-29.09.2016 - Messe Hannover - Hall 17 - Stand A30 + D131 > >Knorr-Bremse IT-Services GmbH >Sitz: Muenchen >Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider >Registergericht Muenchen, HR B 167 268 > >This transmission is intended solely for the addressee and contains confidential information. >If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. >Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. > >-- >Manage your subscription for the Freeipa-devel mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-devel >Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- / Alexander Bokovoy From pvoborni at redhat.com Thu Aug 4 16:18:29 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 4 Aug 2016 18:18:29 +0200 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> Message-ID: <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> On 07/22/2016 07:13 AM, Fraser Tweedale wrote: > On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote: >> Hi, >> >> On 14.7.2016 13:44, Fraser Tweedale wrote: >>> Hi all, >>> >>> The attached patch includes SANs in cert-show output. If you have >>> certs with esoteric altnames (especially any that are more than just >>> ASN.1 string types), please test with those certs. >>> >>> https://fedorahosted.org/freeipa/ticket/6022 >> >> I think it would be better to have a separate attribute for each supported >> SAN type rather than cramming everything into subject_alt_name. That way if >> you care only about a single specific type you won't have to go through all >> the values and parse them. Also it would allow you to use param types >> appropriate to the SAN types (DNSNameParam for DNS names, Principal for >> principal names, etc.) >> >> Nitpick: please don't mix moving existing stuff and adding new stuff in a >> single patch. >> > Updated patches attached. > > Patches 0092..0094 are refactors and bugfixes. > Patch 0090-2 is the main feature (depends on 0092..0094). > > Thanks, > Fraser > bump for review -- Petr Vobornik From lslebodn at redhat.com Fri Aug 5 07:01:26 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 5 Aug 2016 09:01:26 +0200 Subject: [Freeipa-devel] [PATCH] ipa-kdb: Allow to build with samba 4.5 Message-ID: <20160805070126.GA29546@10.4.128.1> ehlo, attached patches fix a build of freeipa on fedora 25 and fedora rawhide. IMHO, this change in krb5pac.h is an ABI change and samba guys should also bump a SONAME to related (private?) libraries. I could not see it; but maybe I overlooked it. LS -------------- next part -------------- >From 02db5adc82c36592f8aef5fd4d5e2f2e27f15b11 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Fri, 5 Aug 2016 08:29:27 +0200 Subject: [PATCH 1/2] ipa-kdb: Allow to build with samba 4.5 daemons/ipa-kdb/ipa_kdb_mspac.c: In function 'filter_logon_info': daemons/ipa-kdb/ipa_kdb_mspac.c:1536:19: error: 'struct PAC_LOGON_INFO' has no member named 'res_group_dom_sid' if (info->info->res_group_dom_sid != NULL && ^~ daemons/ipa-kdb/ipa_kdb_mspac.c:1537:19: error: 'struct PAC_LOGON_INFO' has no member named 'res_groups'; did you mean 'resource_groups'? info->info->res_groups.count != 0) { ^~ mv -f .deps/ipa_kdb_delegation.Tpo .deps/ipa_kdb_delegation.Plo Makefile:806: recipe for target 'ipa_kdb_mspac.lo' failed make[3]: *** [ipa_kdb_mspac.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... Related change in samba https://github.com/samba-team/samba/commit/4406cf792a599724f55777a45efb6367a9bd92b2 Resolves: https://fedorahosted.org/freeipa/ticket/6173 --- daemons/configure.ac | 12 ++++++++++++ daemons/ipa-kdb/ipa_kdb_mspac.c | 9 +++++++++ 2 files changed, 21 insertions(+) diff --git a/daemons/configure.ac b/daemons/configure.ac index 94d66d813728fe4e32f9e3c0eef920d8e2395d8f..5c5a1046397aa97ba18cafc1b81dc2a6fb2dfd34 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -170,6 +170,18 @@ PKG_CHECK_MODULES([SAMBAUTIL], [samba-util]) SAMBA40EXTRA_LIBPATH="-L`$PKG_CONFIG --variable=libdir samba-util`/samba -Wl,-rpath=`$PKG_CONFIG --variable=libdir samba-util`/samba" AC_SUBST(SAMBA40EXTRA_LIBPATH) +bck_cflags="$CFLAGS" +CFLAGS="$NDRPAC_CFLAGS" +AC_CHECK_MEMBER( + [struct PAC_DOMAIN_GROUP_MEMBERSHIP.domain_sid], + [AC_DEFINE([HAVE_STRUCT_PAC_DOMAIN_GROUP_MEMBERSHIP], [1], + [struct PAC_DOMAIN_GROUP_MEMBERSHIP is available.])], + [AC_MSG_NOTICE([struct PAC_DOMAIN_GROUP_MEMBERSHIP is not available])], + [[#include + #include ]]) + +CFLAGS="$bck_cflags" + LIBPDB_NAME="" AC_CHECK_LIB([samba-passdb], [make_pdb_method], diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 80e7055fd6cd7b962eeffbccc675a73d73700793..65cc03565dc06d1052c6acd0c0d6ee7265b37b36 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -20,6 +20,8 @@ * along with this program. If not, see . */ +#include "config.h" + #include "ipa_kdb.h" #include "ipa_mspac.h" #include @@ -1533,10 +1535,17 @@ krb5_error_code filter_logon_info(krb5_context context, /* According to MS-KILE, ResourceGroups must be zero, so check * that it is the case here */ +#ifdef HAVE_STRUCT_PAC_DOMAIN_GROUP_MEMBERSHIP + if (info->info->resource_groups.domain_sid != NULL && + info->info->resource_groups.groups.count != 0) { + return EINVAL; + } +#else if (info->info->res_group_dom_sid != NULL && info->info->res_groups.count != 0) { return EINVAL; } +#endif return 0; } -- 2.9.2 -------------- next part -------------- >From 7d064bc2dda88552f597c1e8dfa2cf176a89ac77 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Fri, 5 Aug 2016 08:34:23 +0200 Subject: [PATCH 2/2] ipa-kdb: Fix unit test after packaging changes in krb5 Resolves: https://fedorahosted.org/freeipa/ticket/6173 --- freeipa.spec.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/freeipa.spec.in b/freeipa.spec.in index 135e9c980011c6c2730c6c29a3c22098e48270d5..7b5bb906ea541da10e0a9f5f9970f5937728ee11 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -108,6 +108,8 @@ BuildRequires: python-netifaces >= 0.10.4 # Build dependencies for unit tests BuildRequires: libcmocka-devel BuildRequires: nss_wrapper +# Required by ipa_kdb_tests +BuildRequires: %{_libdir}/krb5/plugins/kdb/db2.so %if 0%{?with_python3} BuildRequires: python3-devel -- 2.9.2 From tkrizek at redhat.com Fri Aug 5 08:44:33 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Fri, 5 Aug 2016 10:44:33 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Update ipa-replica-install documentation Message-ID: <3fa21f64-a8cd-d73b-d591-5fef2d1b29de@redhat.com> Hi, attached a patch to update man page and doc. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tkrizek-0001-Update-ipa-replica-install-documentation.patch Type: text/x-patch Size: 1671 bytes Desc: not available URL: From mbasti at redhat.com Fri Aug 5 09:50:37 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 5 Aug 2016 11:50:37 +0200 Subject: [Freeipa-devel] [PATCH 0153] Fix ipa-replica-prepare's error message about missing local CA instanc In-Reply-To: <770e0863-006c-9a01-05d8-9c20ed2fca18@redhat.com> References: <04a436fd-bc8b-e57b-d3dd-320b26fb0d68@redhat.com> <770e0863-006c-9a01-05d8-9c20ed2fca18@redhat.com> Message-ID: <2e4d13e7-98ca-eee5-4d49-c0320bd8b830@redhat.com> On 04.08.2016 17:35, Petr Spacek wrote: > On 3.8.2016 22:56, Ben Lipton wrote: >> On 08/01/2016 11:38 AM, Petr Spacek wrote: >>> Hello, >>> >>> Fix ipa-replica-prepare's error message about missing local CA instance >>> >>> ipa-replica-prepare must be run on a replica with CA or all the certs >>> needs to be provided (for CA-less case). >>> >>> The old messages were utterly confusing because they mixed errors about >>> missing certs and missing local CA instance into one text. >>> >>> https://fedorahosted.org/freeipa/ticket/6134 >>> >>> >>> >> The error message in the patch says "must be ran" instead of "must be run". > Thanks! Fixed patch is attached. > > > ACK Pushed to: master: 503d096ebc6a4813c15701454fa3cf7abc7970d7 ipa-4-3: fedee72a5a0e9fbb2b82c4105034857b17f8a5c4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Aug 5 09:52:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 5 Aug 2016 11:52:44 +0200 Subject: [Freeipa-devel] [PATCH] 0096 caacl: fix regression in rule instantiation In-Reply-To: <93487384-dec1-13f2-8e0b-e94dc0baf20a@redhat.com> References: <20160728013118.GA10771@dhcp-40-8.bne.redhat.com> <3131b303-a873-1575-9488-f764c7dd96be@redhat.com> <20160729042103.GK10771@dhcp-40-8.bne.redhat.com> <93487384-dec1-13f2-8e0b-e94dc0baf20a@redhat.com> Message-ID: <46ec3e49-5a1b-ecab-cfc1-63cad9186305@redhat.com> On 04.08.2016 15:09, Martin Basti wrote: > > > > On 29.07.2016 06:21, Fraser Tweedale wrote: >> On Thu, Jul 28, 2016 at 09:56:30AM +0200, Martin Babinsky wrote: >>> On 07/28/2016 03:31 AM, Fraser Tweedale wrote: >>>> The attached patch fixes a kerberos.Principal-related regression. >>>> >>>> Thanks, >>>> Fraser >>>> >>> Hi Fraser, >>> >>> The ticket you linked in the commit message points to a closed milestone. >>> You have to open a new ticket which needs to be triaged. Sorry, those are >>> the processes. >>> >> Filed ticket:https://fedorahosted.org/freeipa/ticket/6146 >> Updated patch attached (rebase and update commit message only). >> >> Thanks, >> Fraser >> >> > > ACK, works for me > > Pushed to master: 9dac0a13f101277948b4ce73b21b1d7ec75848b6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Aug 5 10:10:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 5 Aug 2016 12:10:36 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Update ipa-replica-install documentation In-Reply-To: <3fa21f64-a8cd-d73b-d591-5fef2d1b29de@redhat.com> References: <3fa21f64-a8cd-d73b-d591-5fef2d1b29de@redhat.com> Message-ID: <552fb242-bc2d-f592-cfda-51e246027e9a@redhat.com> On 05.08.2016 10:44, Tomas Krizek wrote: > Hi, > > attached a patch to update man page and doc. > > Tomas > > > > ACK Pushed to master: d8fe5863d297b74efff9ba6bbb2e8134e457d6e4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri Aug 5 10:43:48 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 5 Aug 2016 12:43:48 +0200 Subject: [Freeipa-devel] [PATCHES] Coverity fixes In-Reply-To: <6dcfcd32-05e3-d36c-484a-bb074373af4c@redhat.com> References: <1469440019.18067.66.camel@redhat.com> <6dcfcd32-05e3-d36c-484a-bb074373af4c@redhat.com> Message-ID: On 07/28/2016 01:01 PM, Martin Basti wrote: > > > On 25.07.2016 11:46, Simo Sorce wrote: >> The attached patches fix some minor issues found by coverity, and pull >> in other fixes released by the asn1c project. >> >> Simo. >> >> >> > I cannot build RPMS with this patch, is there any missing build dependency? > > /bin/sh ./libtool --tag=CC --mode=link gcc -Wall -Wshadow > -Wstrict-prototypes -Wpointer-arith -Wcast-align > -Werror-implicit-function-declaration -O2 -g -pipe -Wall > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall > -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare > -Wno-missing-field-initializers -Wl,-z,relro > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o > ipa-client-common.o ipa_krb5.o ../asn1/libipaasn1.la -lkrb5 -lk5crypto -lcom_err > -llber -lldap -lsasl2 -lpopt -lini_config -lbasicobjects -lref_array > -lcollection -lini_config -lini_config > libtool: link: gcc -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith > -Wcast-align -Werror-implicit-function-declaration -O2 -g -pipe -Wall > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall > -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare > -Wno-missing-field-initializers -Wl,-z -Wl,relro > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o > ipa-client-common.o ipa_krb5.o ../asn1/.libs/libipaasn1.a -lkrb5 -lk5crypto > -lcom_err -llber -lldap -lsasl2 -lpopt -lbasicobjects -lref_array -lcollection > -lini_config > ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_decode_uper': > /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:897: > undefined reference to `uper_open_type_get' > ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_encode_uper': > /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:982: > undefined reference to `uper_open_type_put' > ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function > `SEQUENCE_handle_extensions': > /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1285: > undefined reference to `uper_open_type_put' > ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function `SEQUENCE_decode_uper': > /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1187: > undefined reference to `uper_open_type_get' > /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1203: > undefined reference to `uper_open_type_skip' > collect2: error: ld returned 1 exit status > > Martin^2 > Bumping. Was it temporary issue or issue in the patch? -- Petr Vobornik From mbasti at redhat.com Fri Aug 5 11:29:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 5 Aug 2016 13:29:03 +0200 Subject: [Freeipa-devel] External plugin integration In-Reply-To: <20160804154920.obmldg6bxip4ev7b@redhat.com> References: <20160804154920.obmldg6bxip4ev7b@redhat.com> Message-ID: <7d9f1b5b-12ed-5355-ef26-f9ba9a073dde@redhat.com> On 04.08.2016 17:49, Alexander Bokovoy wrote: > Hi! > > I've stumbled into an interesting problem. > > Suppose, I have a plugin that adds schema and a subtree where entries it > manages will be stored. This subtree will have ACIs applied based on the > plugin permissions' configuration. Now, I put schema file in > /usr/ipa/share, and updates file in /usr/share/ipa/updates, and also add > plugin code to the ipaserver/plugins/ (let's say, rpm does it for me). > Next, I want to install IPA server. The install will run through up to > server upgrade phase which will fail because generation of ACIs will > reference schema attributes/classes which aren't loaded to the dirsrv by > installer. How to solve it? > Installer uses hard-coded list of schema files and this is a third-party > plugin, it needs to extend the list of active schema files. > > If we can define a place where third-party plugins could drop schema and > we just load everything from there before processing updates, it would > probably be enough. > TLDR: you don't without modifications in current IPA code, or it will be huge hack I think, this is a part of "Support of 3rd party plugins" effort, but it has not been designed yet. I would like to avoid any ad-hoc solution. Maybe we should create a desing page and gathering requirements, you have a lot of them already :). Martin^2 From tbordaz at redhat.com Fri Aug 5 11:33:17 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 5 Aug 2016 13:33:17 +0200 Subject: [Freeipa-devel] [PATCH 0196] baseldap: Fix MidairCollision instantiation during entry modification In-Reply-To: <20160726152219.u67pdvfxg4mwkogc@redhat.com> References: <20160726152219.u67pdvfxg4mwkogc@redhat.com> Message-ID: <57A4797D.2070501@redhat.com> On 07/26/2016 05:22 PM, Alexander Bokovoy wrote: > On Tue, 26 Jul 2016, Martin Babinsky wrote: >> Fix for https://fedorahosted.org/freeipa/ticket/6097 >> >> Since this issue was found during investigation of other ticket[1], >> you can test it by performing steps to reproduce #6041, but instead >> of internal error you should see the MidairCollision raised as public >> error with the right error message. >> >> [1] https://fedorahosted.org/freeipa/ticket/6041 > I have a preliminary patch for slapi-nis to fix 6041 (attached). The slapi-nis patch looks good to me. Ludwig may give the final ACK. thanks thierry > > As for this fix -- ACK. > >> >> -- >> Martin^3 Babinsky > >> From 8f0d6dab08f61fe2fd1ad64a63f7ab91fc5227d4 Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Mon, 25 Jul 2016 14:05:08 +0200 >> Subject: [PATCH] baseldap: Fix MidairCollision instantiation during >> entry >> modification >> >> https://fedorahosted.org/freeipa/ticket/6097 >> --- >> ipaserver/plugins/baseldap.py | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/ipaserver/plugins/baseldap.py >> b/ipaserver/plugins/baseldap.py >> index >> 6107e43a6ee17d9b9a63d9dc109664d8b232069f..f7844e3e7c59c259b9c8367d135b2dbefc3f0016 >> 100644 >> --- a/ipaserver/plugins/baseldap.py >> +++ b/ipaserver/plugins/baseldap.py >> @@ -1466,7 +1466,7 @@ class LDAPUpdate(LDAPQuery, crud.Update): >> entry_attrs.dn, attrs_list) >> except errors.NotFound: >> raise errors.MidairCollision( >> - format=_('the entry was deleted while being modified') >> + message=_('the entry was deleted while being modified') >> ) >> >> self.obj.get_indirect_members(entry_attrs, attrs_list) >> @@ -2344,7 +2344,7 @@ class BaseLDAPModAttribute(LDAPQuery): >> entry_attrs.dn, attrs_list) >> except errors.NotFound: >> raise errors.MidairCollision( >> - format=_('the entry was deleted while being modified') >> + message=_('the entry was deleted while being modified') >> ) >> >> for callback in self.get_callbacks('post'): >> -- >> 2.7.4 >> > >> -- >> Manage your subscription for the Freeipa-devel mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Aug 5 11:58:19 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Aug 2016 14:58:19 +0300 Subject: [Freeipa-devel] External plugin integration In-Reply-To: <7d9f1b5b-12ed-5355-ef26-f9ba9a073dde@redhat.com> References: <20160804154920.obmldg6bxip4ev7b@redhat.com> <7d9f1b5b-12ed-5355-ef26-f9ba9a073dde@redhat.com> Message-ID: <20160805115819.jaboekouuu5ph3pq@redhat.com> On Fri, 05 Aug 2016, Martin Basti wrote: > > >On 04.08.2016 17:49, Alexander Bokovoy wrote: >>Hi! >> >>I've stumbled into an interesting problem. >> >>Suppose, I have a plugin that adds schema and a subtree where entries it >>manages will be stored. This subtree will have ACIs applied based on the >>plugin permissions' configuration. Now, I put schema file in >>/usr/ipa/share, and updates file in /usr/share/ipa/updates, and also add >>plugin code to the ipaserver/plugins/ (let's say, rpm does it for me). >>Next, I want to install IPA server. The install will run through up to >>server upgrade phase which will fail because generation of ACIs will >>reference schema attributes/classes which aren't loaded to the dirsrv by >>installer. How to solve it? >>Installer uses hard-coded list of schema files and this is a third-party >>plugin, it needs to extend the list of active schema files. >> >>If we can define a place where third-party plugins could drop schema and >>we just load everything from there before processing updates, it would >>probably be enough. >> > >TLDR: you don't without modifications in current IPA code, or it will >be huge hack So far all I needed are following modifications which really boil down to: - introduce /usr/share/ipa/schema.d to hold third-party schema files - add support to read the schema files from /usr/share/ipa/schema.d to dsintance upgrade step and to ipa-server-upgrade That's all. Since I'm adding a new directory, I needed to update Makefile.am and install/configure.ac which requires regeneration of Makefile/configure files. You'd need to remove install/Makefile and run 'make bootstrap-autogen' to make sure the install/Makefile is recreated and install/share/schema.d/Makefile is created. >I think, this is a part of "Support of 3rd party plugins" effort, but >it has not been designed yet. I would like to avoid any ad-hoc >solution. >Maybe we should create a desing page and gathering requirements, you >have a lot of them already :). I'm working on the whole package for FleetCommander integration and I'll produce a howto based on it. So far, there was no need to have anything dramatic. -- / Alexander Bokovoy -------------- next part -------------- From 6a6383d234607c33b402df93e923478e9b64c000 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 5 Aug 2016 13:04:19 +0300 Subject: [PATCH 2/2] WIP: support schema files from third-party plugins Allow upgrade process to include schema files from third-party plugins installed in /usr/share/ipa/schema.d/*.schema. The directory /usr/shar/eipa/schema.d is owned by the server-common subpackage and therefore third-party plugins should depend on freeipa-server-common (ipa-server-common) package in their package dependencies. --- freeipa.spec.in | 5 ++++- install/configure.ac | 1 + install/share/Makefile.am | 1 + install/share/schema.d/Makefile.am | 16 ++++++++++++++++ install/share/schema.d/README | 11 +++++++++++ ipaplatform/base/paths.py | 1 + ipaserver/install/dsinstance.py | 16 +++++++++++++++- ipaserver/install/server/upgrade.py | 3 +++ 8 files changed, 52 insertions(+), 2 deletions(-) create mode 100644 install/share/schema.d/Makefile.am create mode 100644 install/share/schema.d/README diff --git a/freeipa.spec.in b/freeipa.spec.in index 135e9c9..8acb3fc 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -871,6 +871,8 @@ mkdir -p %{buildroot}%{_sysconfdir}/cron.d mkdir -p %{buildroot}%{_sysconfdir}/ipa/custodia +mkdir -p %{buildroot}%{_usr}/share/ipa/schema.d + %endif # ONLY_CLIENT @@ -1248,7 +1250,8 @@ fi %ghost %{_localstatedir}/lib/ipa/pki-ca/publish %ghost %{_localstatedir}/named/dyndb-ldap/ipa %dir %attr(0700,root,root) %{_sysconfdir}/ipa/custodia - +%dir %{_usr}/share/ipa/schema.d +%attr(0644,root,root) %{_usr}/share/ipa/schema.d/README %files server-dns %defattr(-,root,root,-) diff --git a/install/configure.ac b/install/configure.ac index b5f77bf..81f17b9 100644 --- a/install/configure.ac +++ b/install/configure.ac @@ -88,6 +88,7 @@ AC_CONFIG_FILES([ share/advise/Makefile share/advise/legacy/Makefile share/profiles/Makefile + share/schema.d/Makefile ui/Makefile ui/css/Makefile ui/src/Makefile diff --git a/install/share/Makefile.am b/install/share/Makefile.am index cd1c164..d8845ee 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -3,6 +3,7 @@ NULL = SUBDIRS = \ advise \ profiles \ + schema.d \ $(NULL) appdir = $(IPA_DATA_DIR) diff --git a/install/share/schema.d/Makefile.am b/install/share/schema.d/Makefile.am new file mode 100644 index 0000000..0fef87f --- /dev/null +++ b/install/share/schema.d/Makefile.am @@ -0,0 +1,16 @@ +NULL = + +SUBDIRS = \ + $(NULL) + +appdir = $(IPA_DATA_DIR)/schema.d +app_DATA = README \ + $(NULL) + +EXTRA_DIST = \ + $(app_DATA) \ + $(NULL) + +MAINTAINERCLEANFILES = \ + *~ \ + Makefile.in diff --git a/install/share/schema.d/README b/install/share/schema.d/README new file mode 100644 index 0000000..eb8c503 --- /dev/null +++ b/install/share/schema.d/README @@ -0,0 +1,11 @@ +This directory is indended to store schema files for 3rd-party plugins. + +Each schema file should be named NN-description.schema where NN is a number 00..90. + +The schema files from this directory are merged together with the core IPA +schema files during the run of ipa-server-upgrade utility. Therefore, they are +also installed when upgrade happens within the process of ipa-server-install. + +The directory is installed as /usr/share/ipa/schema.d and is owned by a +freeipa-server-common package. Therefore, a 3rd-party plugin would need to +depend on the freeipa-server-common package if it delivers the schema file(s). diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index b1fedf5..fff55a3 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -354,6 +354,7 @@ class BasePathNamespace(object): IPA_CUSTODIA_SOCKET = '/run/httpd/ipa-custodia.sock' IPA_CUSTODIA_AUDIT_LOG = '/var/log/ipa-custodia.audit.log' IPA_GETKEYTAB = '/usr/sbin/ipa-getkeytab' + EXTERNAL_SCHEMA_DIR = '/usr/share/ipa/schema.d' @property def USER_CACHE_PATH(self): diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index c93b3b4..2ffd9b4 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -180,6 +180,18 @@ def get_domain_level(api=api): return int(entry.single_value['ipaDomainLevel']) +def get_all_external_schema_files(root): + """Get all schema files""" + f = [] + for path, subdirs, files in os.walk(root): + for name in files: + if fnmatch.fnmatch(name, "*.schema"): + f.append(os.path.join(path, name)) + if not recursive: + break + return f + + INF_TEMPLATE = """ [General] FullMachineName= $FQDN @@ -656,7 +668,9 @@ class DsInstance(service.Service): conn.unbind() def apply_updates(self): - data_upgrade = upgradeinstance.IPAUpgrade(self.realm) + schema_files = get_all_external_schema_files(paths.EXTERNAL_SCHEMA_DIR) + data_upgrade = upgradeinstance.IPAUpgrade(self.realm, + schema_files=schema_files) try: data_upgrade.create_instance() except Exception as e: diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index 4342717..2d6b8cb 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1817,6 +1817,9 @@ def upgrade(): realm = api.env.realm schema_files = [os.path.join(ipautil.SHARE_DIR, f) for f in dsinstance.ALL_SCHEMA_FILES] + + schema_files.extend(dsinstance.get_all_external_schema_files( + paths.EXTERNAL_SCHEMA_DIR)) data_upgrade = IPAUpgrade(realm, schema_files=schema_files) try: -- 2.7.4 From mbasti at redhat.com Fri Aug 5 12:08:43 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 5 Aug 2016 14:08:43 +0200 Subject: [Freeipa-devel] External plugin integration In-Reply-To: <20160805115819.jaboekouuu5ph3pq@redhat.com> References: <20160804154920.obmldg6bxip4ev7b@redhat.com> <7d9f1b5b-12ed-5355-ef26-f9ba9a073dde@redhat.com> <20160805115819.jaboekouuu5ph3pq@redhat.com> Message-ID: <5ae4e770-8b63-82be-6acf-e1ab45d519f2@redhat.com> On 05.08.2016 13:58, Alexander Bokovoy wrote: > On Fri, 05 Aug 2016, Martin Basti wrote: >> >> >> On 04.08.2016 17:49, Alexander Bokovoy wrote: >>> Hi! >>> >>> I've stumbled into an interesting problem. >>> >>> Suppose, I have a plugin that adds schema and a subtree where >>> entries it >>> manages will be stored. This subtree will have ACIs applied based on >>> the >>> plugin permissions' configuration. Now, I put schema file in >>> /usr/ipa/share, and updates file in /usr/share/ipa/updates, and also >>> add >>> plugin code to the ipaserver/plugins/ (let's say, rpm does it for me). >>> Next, I want to install IPA server. The install will run through up to >>> server upgrade phase which will fail because generation of ACIs will >>> reference schema attributes/classes which aren't loaded to the >>> dirsrv by >>> installer. How to solve it? >>> Installer uses hard-coded list of schema files and this is a >>> third-party >>> plugin, it needs to extend the list of active schema files. >>> >>> If we can define a place where third-party plugins could drop schema >>> and >>> we just load everything from there before processing updates, it would >>> probably be enough. >>> >> >> TLDR: you don't without modifications in current IPA code, or it will >> be huge hack > So far all I needed are following modifications which really boil down > to: > - introduce /usr/share/ipa/schema.d to hold third-party schema files > - add support to read the schema files from /usr/share/ipa/schema.d > to dsintance upgrade step and to ipa-server-upgrade > > That's all. Since I'm adding a new directory, I needed to update > Makefile.am and install/configure.ac which requires regeneration of > Makefile/configure files. You'd need to remove install/Makefile and run > 'make bootstrap-autogen' to make sure the install/Makefile is recreated > and install/share/schema.d/Makefile is created. > >> I think, this is a part of "Support of 3rd party plugins" effort, but >> it has not been designed yet. I would like to avoid any ad-hoc solution. >> Maybe we should create a desing page and gathering requirements, you >> have a lot of them already :). > I'm working on the whole package for FleetCommander integration and I'll > produce a howto based on it. So far, there was no need to have anything > dramatic. > You introduced a new convention, +Each schema file should be named NN-description.schema where NN is a number 00..90. Currently all LDAP schema files are *.ldif, why do not stay with this naming? Martin^2 From lslebodn at redhat.com Fri Aug 5 12:13:37 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 5 Aug 2016 14:13:37 +0200 Subject: [Freeipa-devel] [PATCHES] Coverity fixes In-Reply-To: References: <1469440019.18067.66.camel@redhat.com> <6dcfcd32-05e3-d36c-484a-bb074373af4c@redhat.com> Message-ID: <20160805121337.GG6891@10.4.128.1> On (05/08/16 12:43), Petr Vobornik wrote: >On 07/28/2016 01:01 PM, Martin Basti wrote: >> >> >> On 25.07.2016 11:46, Simo Sorce wrote: >>> The attached patches fix some minor issues found by coverity, and pull >>> in other fixes released by the asn1c project. >>> >>> Simo. >>> >>> >>> >> I cannot build RPMS with this patch, is there any missing build dependency? >> >> /bin/sh ./libtool --tag=CC --mode=link gcc -Wall -Wshadow >> -Wstrict-prototypes -Wpointer-arith -Wcast-align >> -Werror-implicit-function-declaration -O2 -g -pipe -Wall >> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall >> -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare >> -Wno-missing-field-initializers -Wl,-z,relro >> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o >> ipa-client-common.o ipa_krb5.o ../asn1/libipaasn1.la -lkrb5 -lk5crypto -lcom_err >> -llber -lldap -lsasl2 -lpopt -lini_config -lbasicobjects -lref_array >> -lcollection -lini_config -lini_config >> libtool: link: gcc -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith >> -Wcast-align -Werror-implicit-function-declaration -O2 -g -pipe -Wall >> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall >> -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare >> -Wno-missing-field-initializers -Wl,-z -Wl,relro >> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o >> ipa-client-common.o ipa_krb5.o ../asn1/.libs/libipaasn1.a -lkrb5 -lk5crypto >> -lcom_err -llber -lldap -lsasl2 -lpopt -lbasicobjects -lref_array -lcollection >> -lini_config >> ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_decode_uper': >> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:897: >> undefined reference to `uper_open_type_get' >> ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_encode_uper': >> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:982: >> undefined reference to `uper_open_type_put' >> ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function >> `SEQUENCE_handle_extensions': >> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1285: >> undefined reference to `uper_open_type_put' >> ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function `SEQUENCE_decode_uper': >> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1187: >> undefined reference to `uper_open_type_get' >> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1203: >> undefined reference to `uper_open_type_skip' >> collect2: error: ld returned 1 exit status >> >> Martin^2 >> > >Bumping. Was it temporary issue or issue in the patch? > I could not see such error. However, these patches would be good to test with coverity. We need to use fedora rawhide for testing due to BuildRequires in freeipa.spec. But C-part of freeIPA cannot be compiled on rawhide due to new samba (4.5). Patches are already on the list. LS From pvomacka at redhat.com Fri Aug 5 12:15:53 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 5 Aug 2016 14:15:53 +0200 Subject: [Freeipa-devel] [PATCH] 0100: Fix question marks in adders in topology graph Message-ID: Hello, Please review attached patch. https://fedorahosted.org/freeipa/ticket/6175 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0100-Fix-unicode-characters-in-ca-and-domain-adders.patch Type: text/x-patch Size: 1357 bytes Desc: not available URL: From lslebodn at redhat.com Fri Aug 5 12:16:52 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 5 Aug 2016 14:16:52 +0200 Subject: [Freeipa-devel] [PATCH] ipa_pwd_extop: Fix warning declaration shadows previous Message-ID: <20160805121651.GH6891@10.4.128.1> ehlo, attached patches fixes few compiler warnings in ipa-extop. Sorry for not following naming convention for patches. But I do not remeber my numer and you will use github/pagure anyway. LS -------------- next part -------------- >From 8a3e8c5e35749f82336e6375e91d7203b1072714 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Fri, 5 Aug 2016 12:00:55 +0000 Subject: [PATCH 1/4] ipa_pwd_extop: Fix warning declaration shadows previous local MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ipa_pwd_extop.c:397:19: warning: declaration of ?target_sdn? shadows a previous local [-Wshadow] Slapi_DN *target_sdn; ^~~~~~~~~~ ipa_pwd_extop.c:212:16: note: shadowed declaration is here Slapi_DN *target_sdn = NULL; ^~~~~~~~~~ --- daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 1 - 1 file changed, 1 deletion(-) 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 3c2c44f6198bf74615fff1ae231a48bed77526ee..74ddfdf87ab19f9fe65b488f78c3b4217544ab2f 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 @@ -394,7 +394,6 @@ parse_req_done: if (dn) { Slapi_DN *bind_sdn; - Slapi_DN *target_sdn; /* if the user changing the password is self, we must request the * old password and verify it matches the current one before -- 2.7.4 -------------- next part -------------- >From 09d32bb149d52d79e4b4cb58fdc3d49bdda81115 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Fri, 5 Aug 2016 12:03:07 +0000 Subject: [PATCH 2/4] =?UTF-8?q?ipa-pwd-extop:=20Fix=20warning=20assignment?= =?UTF-8?q?=20discards=20=E2=80=98const=E2=80=99=20qualifier=20from=20poin?= =?UTF-8?q?ter?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ipa_pwd_extop.c: In function ?ipapwd_chpwop?: ipa_pwd_extop.c:337:13: warning: assignment discards ?const? qualifier from pointer target type [-Wdiscarded-qualifiers] target_dn = slapi_sdn_get_ndn(target_sdn); ^ --- daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 74ddfdf87ab19f9fe65b488f78c3b4217544ab2f..6a87a2786c3fb762e07e40509c663a84134978a5 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 @@ -210,7 +210,7 @@ static int ipapwd_chpwop(Slapi_PBlock *pb, struct ipapwd_krbcfg *krbcfg) char *principal = NULL; Slapi_PBlock *chpwop_pb = NULL; Slapi_DN *target_sdn = NULL; - char *target_dn = NULL; + const char *target_dn = NULL; /* Get the ber value of the extended operation */ slapi_pblock_get(pb, SLAPI_EXT_OP_REQ_VALUE, &extop_value); -- 2.7.4 From abokovoy at redhat.com Fri Aug 5 12:28:41 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Aug 2016 15:28:41 +0300 Subject: [Freeipa-devel] External plugin integration In-Reply-To: <5ae4e770-8b63-82be-6acf-e1ab45d519f2@redhat.com> References: <20160804154920.obmldg6bxip4ev7b@redhat.com> <7d9f1b5b-12ed-5355-ef26-f9ba9a073dde@redhat.com> <20160805115819.jaboekouuu5ph3pq@redhat.com> <5ae4e770-8b63-82be-6acf-e1ab45d519f2@redhat.com> Message-ID: <20160805122841.y3ewahax4eppersq@redhat.com> On Fri, 05 Aug 2016, Martin Basti wrote: > > >On 05.08.2016 13:58, Alexander Bokovoy wrote: >>On Fri, 05 Aug 2016, Martin Basti wrote: >>> >>> >>>On 04.08.2016 17:49, Alexander Bokovoy wrote: >>>>Hi! >>>> >>>>I've stumbled into an interesting problem. >>>> >>>>Suppose, I have a plugin that adds schema and a subtree where >>>>entries it >>>>manages will be stored. This subtree will have ACIs applied >>>>based on the >>>>plugin permissions' configuration. Now, I put schema file in >>>>/usr/ipa/share, and updates file in /usr/share/ipa/updates, and >>>>also add >>>>plugin code to the ipaserver/plugins/ (let's say, rpm does it for me). >>>>Next, I want to install IPA server. The install will run through up to >>>>server upgrade phase which will fail because generation of ACIs will >>>>reference schema attributes/classes which aren't loaded to the >>>>dirsrv by >>>>installer. How to solve it? >>>>Installer uses hard-coded list of schema files and this is a >>>>third-party >>>>plugin, it needs to extend the list of active schema files. >>>> >>>>If we can define a place where third-party plugins could drop >>>>schema and >>>>we just load everything from there before processing updates, it would >>>>probably be enough. >>>> >>> >>>TLDR: you don't without modifications in current IPA code, or it >>>will be huge hack >>So far all I needed are following modifications which really boil down >>to: >>- introduce /usr/share/ipa/schema.d to hold third-party schema files >>- add support to read the schema files from /usr/share/ipa/schema.d >> to dsintance upgrade step and to ipa-server-upgrade >> >>That's all. Since I'm adding a new directory, I needed to update >>Makefile.am and install/configure.ac which requires regeneration of >>Makefile/configure files. You'd need to remove install/Makefile and run >>'make bootstrap-autogen' to make sure the install/Makefile is recreated >>and install/share/schema.d/Makefile is created. >> >>>I think, this is a part of "Support of 3rd party plugins" effort, >>>but it has not been designed yet. I would like to avoid any ad-hoc >>>solution. >>>Maybe we should create a desing page and gathering requirements, >>>you have a lot of them already :). >>I'm working on the whole package for FleetCommander integration and I'll >>produce a howto based on it. So far, there was no need to have anything >>dramatic. >> > >You introduced a new convention, > >+Each schema file should be named NN-description.schema where NN is a >number 00..90. > >Currently all LDAP schema files are *.ldif, why do not stay with this >naming? Because I wanted to unify it with other publicly visible component, /usr/share/ipa/updates. In updates directory we have update files following the same pattern, NN-description.update. Unfortunately, I just realised that extension has probably to be .ldif for 389-ds to correctly recognize it when files are loaded and upgraded via 398-ds tools. I fixed the extension part. Testing the whole setup now. -- / Alexander Bokovoy From pvomacka at redhat.com Fri Aug 5 12:33:01 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 5 Aug 2016 14:33:01 +0200 Subject: [Freeipa-devel] [PATCH] webui: Fix coverity bugs In-Reply-To: References: <17dedc13-dab5-4ae2-5a7b-d7921458a46f@redhat.com> <20160729132534.sdsdlda5c2gtvqj6@redhat.com> Message-ID: <8c539d0a-29ee-30ba-33eb-90aa0698f583@redhat.com> On 08/01/2016 05:53 PM, Petr Vobornik wrote: > On 07/29/2016 03:25 PM, Alexander Bokovoy wrote: >> On Fri, 29 Jul 2016, Pavel Vomacka wrote: >>> Hello, >>> >>> please review attached patches which fixes errors from Coverity. >>> >>> -- >>> Pavel^3 Vomacka >>> >>> From 0391289b3f6844897e2a9f3ae549bd4c33233ffc Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Mon, 25 Jul 2016 10:36:47 +0200 >>> Subject: [PATCH 01/13] Coverity - null pointer exception >>> >>> Variable 'option' can be null and there will be error of reading >>> property of null. >>> --- >>> install/ui/src/freeipa/widget.js | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/install/ui/src/freeipa/widget.js >>> b/install/ui/src/freeipa/widget.js >>> index >>> 9151ebac9438e9e674f81bfb1ccfe7a63872b1ae..cfdf5d4750951e4549c16a2b9b9c355f61e90c39 >>> 100644 >>> --- a/install/ui/src/freeipa/widget.js >>> +++ b/install/ui/src/freeipa/widget.js >>> @@ -2249,7 +2249,7 @@ IPA.option_widget_base = function(spec, that) { >>> var child_values = []; >>> var option = that.get_option(value); >>> >>> - if (option.widget) { >>> + if (option && option.widget) { >>> child_values = option.widget.save(); >>> values.push.apply(values, child_values); >>> } >>> -- >>> 2.5.5 >>> >> ACK > ACK > >>> From 6df8e608232e25daa9aefe4fccbdeca4dbaf1998 Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Mon, 25 Jul 2016 10:43:00 +0200 >>> Subject: [PATCH 02/13] Coverity - null pointer exception >>> >>> Variable 'row' could be null in some cases. And set css to variable >>> which is pointing to null >>> causes error. Therefore there is new check. >>> --- >>> install/ui/src/freeipa/widget.js | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/install/ui/src/freeipa/widget.js >>> b/install/ui/src/freeipa/widget.js >>> index >>> cfdf5d4750951e4549c16a2b9b9c355f61e90c39..5844436abf090f12d5a9d65efe7a1aaee14097e2 >>> 100644 >>> --- a/install/ui/src/freeipa/widget.js >>> +++ b/install/ui/src/freeipa/widget.js >>> @@ -5766,6 +5766,8 @@ exp.fluid_layout = IPA.fluid_layout = >>> function(spec) { >>> that.on_visible_change = function(event) { >>> >>> var row = that._get_row(event); >>> + if (!row) return; >>> + >>> if (event.visible) { >>> row.css('display', ''); >>> } else { >>> -- >>> 2.5.5 >>> >> ACK > > ACK > >> >>> From 6f2ddc9e1c5323a640bdf744d2da00bfee7ab766 Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Mon, 25 Jul 2016 13:48:16 +0200 >>> Subject: [PATCH 03/13] Coverity - not initialized variable >>> >>> The variable hasn't been initialized, now it is set to null by default. >>> --- >>> install/ui/src/freeipa/widget.js | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/install/ui/src/freeipa/widget.js >>> b/install/ui/src/freeipa/widget.js >>> index >>> 5844436abf090f12d5a9d65efe7a1aaee14097e2..43804c5ea524ca741017d02f6e12ccf60d50b5df >>> 100644 >>> --- a/install/ui/src/freeipa/widget.js >>> +++ b/install/ui/src/freeipa/widget.js >>> @@ -1047,7 +1047,7 @@ IPA.multivalued_widget = function(spec) { >>> >>> that.child_spec = spec.child_spec; >>> that.size = spec.size || 30; >>> - that.undo_control; >>> + that.undo_control = null; >>> that.initialized = true; >>> that.updating = false; >>> >>> -- >>> 2.5.5 >>> >> ACK > ACK > >> >>> From b9ddd32ec45aadae5a79e372c3e1b70990071e60 Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Mon, 25 Jul 2016 14:42:50 +0200 >>> Subject: [PATCH 04/13] Coverity - identical code for different branches >>> >>> In both cases when the condition is true or false ut is set the same >>> value. >>> Changed to assign the value directly. >>> --- >>> install/ui/src/freeipa/topology_graph.js | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/install/ui/src/freeipa/topology_graph.js >>> b/install/ui/src/freeipa/topology_graph.js >>> index >>> ce2ebeaff611987ae27f2655b5da80bdcd1b4f8a..712d38fbe67e87ffa773e0a3a1f8937e9595c9a6 >>> 100644 >>> --- a/install/ui/src/freeipa/topology_graph.js >>> +++ b/install/ui/src/freeipa/topology_graph.js >>> @@ -325,8 +325,8 @@ topology_graph.TopoGraph = declare([Evented], { >>> off = dir ? -1 : 1, // determines shift direction of >>> curve >>> ns = 5, // shift on normal vector >>> s = target_count > 1 ? 1 : 0, // shift from center? >>> - spad = d.left ? 18 : 18, // source padding >>> - tpad = d.right ? 18 : 18, // target padding >>> + spad = d.left = 18, // source padding >>> + tpad = d.right = 18, // target padding >>> sourceX = d.source.x + (spad * ux) + off * nx * ns * s, >>> sourceY = d.source.y + (spad * uy) + off * ny * ns * s, >>> targetX = d.target.x - (tpad * ux) + off * nx * ns * s, >>> -- >>> 2.5.5 >>> >> ACK > NACK > > following lines are not equivalent > spad = d.left ? 18 : 18 > spad = d.left = 18 > > same with tpad Fixed >>> From f1f2b55247d6c7f41f8053f372a47945c93fc8a4 Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Mon, 25 Jul 2016 14:52:15 +0200 >>> Subject: [PATCH 05/13] Coverity - Accesing attribute of null >>> >>> There is a possibility that widget is null and then there could be an >>> error. >>> Therefore there is new check of widget variable. >>> --- >>> install/ui/src/freeipa/widgets/APIBrowserWidget.js | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> index >>> 1a3726190d4a5d628a8f7c2b564c4c9f6e7cea1f..50c2989fcc126585787df61cdd19493632ed37b9 >>> 100644 >>> --- a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> +++ b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> @@ -252,7 +252,7 @@ widgets.APIBrowserWidget = declare([Stateful, >>> Evented], { >>> } >>> >>> // switch widget >>> - if (!widget.el) widget.render(); >>> + if (widget && !widget.el) widget.render(); >>> if (this.current_details_w !== widget) { >>> this.details_el.empty(); >>> this.details_el.append(widget.el); >>> -- >>> 2.5.5 >>> >> ACK > ACK > >>> From 1476b5ed3ab5c4ec55f3ed20ad07a5b88cfd45f2 Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Mon, 25 Jul 2016 16:47:22 +0200 >>> Subject: [PATCH 06/13] Coverity - removed dead code >>> >>> There cannot be string value because of previous checks. >>> --- >>> install/ui/src/freeipa/dns.js | 12 ++++-------- >>> 1 file changed, 4 insertions(+), 8 deletions(-) >>> >>> diff --git a/install/ui/src/freeipa/dns.js >>> b/install/ui/src/freeipa/dns.js >>> index >>> 2d424aeae8ef735d02426a0f08b6261ec2f04c19..822c0b3cedb3988563c0a1f83862f56e95eed21b >>> 100644 >>> --- a/install/ui/src/freeipa/dns.js >>> +++ b/install/ui/src/freeipa/dns.js >>> @@ -1509,14 +1509,10 @@ IPA.dns.record_prepare_editor_for_type = >>> function(type, fields, widgets, update) >>> >>> //create editor widget >>> var widget = {}; >>> - if (typeof attribute === 'string') { >>> - widget.name = attribute; >>> - } else { >>> - widget.name = attribute.name; >>> - set_defined(attribute.$type, widget, '$type'); >>> - set_defined(attribute.options, widget, 'options'); >>> - copy_obj(widget, attribute.widget_opt); >>> - } >>> + widget.name = attribute.name; >>> + set_defined(attribute.$type, widget, '$type'); >>> + set_defined(attribute.options, widget, 'options'); >>> + copy_obj(widget, attribute.widget_opt); >>> section.widgets.push(widget); >>> } >>> }; >>> -- >>> 2.5.5 >>> >> ACK > ACK > >> >>> From b1dd66f3b08889b51430d9176035366cb055324e Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Mon, 25 Jul 2016 17:44:56 +0200 >>> Subject: [PATCH 07/13] Coverity - true branch can't be executed >>> >>> The 'data' variable is always false because of previous condition. >>> Therefore there is direct assignment. >>> --- >>> install/ui/src/freeipa/rpc.js | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/install/ui/src/freeipa/rpc.js >>> b/install/ui/src/freeipa/rpc.js >>> index >>> a185585f4176658e299e7e92434522c936cc36b4..88aaf6ede72ea69495c369dd74c657d0419a3605 >>> 100644 >>> --- a/install/ui/src/freeipa/rpc.js >>> +++ b/install/ui/src/freeipa/rpc.js >>> @@ -372,7 +372,7 @@ rpc.command = function(spec) { >>> error_handler.call(this, xhr, text_status, /* >>> error_thrown */ { >>> name: text.get('@i18n:errors.http_error', 'HTTP >>> Error')+' '+xhr.status, >>> url: this.url, >>> - message: data ? xhr.statusText : >>> text.get('@i18n:errors.no_response', 'No response') >>> + message: text.get('@i18n:errors.no_response', 'No >>> response') >>> }); >>> >>> } else if (IPA.version && data.version && IPA.version !== >>> data.version) { >>> -- >>> 2.5.5 >>> >> ACK > > ACK - patch fixes the issue. > > But I wonder if it should be rather: > message: xhr ? xhr.statusText : text.get('@i18n:errors.no_response', > 'No response') > > don't remember. That's true, fixed. >> >>> From 463f24936469d87890b666dfd7edabbe90541491 Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Mon, 25 Jul 2016 17:49:50 +0200 >>> Subject: [PATCH 08/13] Coverity - true branch can't be executed >>> >>> The 'result' variable is always false because of previous condition. >>> Therefore there is direct assignment. >>> --- >>> install/ui/src/freeipa/rpc.js | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/install/ui/src/freeipa/rpc.js >>> b/install/ui/src/freeipa/rpc.js >>> index >>> 88aaf6ede72ea69495c369dd74c657d0419a3605..30a5366787974b2d127114f7683d0589ed332f5a >>> 100644 >>> --- a/install/ui/src/freeipa/rpc.js >>> +++ b/install/ui/src/freeipa/rpc.js >>> @@ -628,7 +628,7 @@ rpc.batch_command = function(spec) { >>> >>> if (!result) { >>> name = text.get('@i18n:errors.internal_error', >>> 'Internal Error')+' '+xhr.status; >>> - message = result ? xhr.statusText : >>> text.get('@i18n:errors.internal_error', 'Internal Error'); >>> + message = text.get('@i18n:errors.internal_error', >>> 'Internal Error'); >>> >>> that.errors.add(command, name, message, text_status); >>> >>> -- >>> 2.5.5 >>> >> ACK > same as previous Fixed as well. >>> From c0ba1c141b6191e2a7ef33bc9eaaad5c970f9d0e Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Mon, 25 Jul 2016 18:25:36 +0200 >>> Subject: [PATCH 09/13] Coverity - null pointer dereference >>> >>> The 'obj' variable could be null, so there could be error when it is >>> used. >>> A new check that 'obj' is not false is added. >>> --- >>> install/ui/src/freeipa/widgets/browser_widgets.js | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/install/ui/src/freeipa/widgets/browser_widgets.js >>> b/install/ui/src/freeipa/widgets/browser_widgets.js >>> index >>> 57ad2bd984ea35f03b302b59fc1d014def162bd8..91bb850a638fd6f16f207b1111d126fbb4fe2dd8 >>> 100644 >>> --- a/install/ui/src/freeipa/widgets/browser_widgets.js >>> +++ b/install/ui/src/freeipa/widgets/browser_widgets.js >>> @@ -427,11 +427,11 @@ widgets.browser_widgets.CommandDetailWidget = >>> declare([base], { >>> if (i>0) { >>> out_params_cnt.append(', '); >>> } >>> - if (!param) { >>> - out_params_cnt.append(param_name); >>> - } else { >>> + if (param && obj) { >>> var link = this.render_param_link(obj.name, >>> param_name); >>> out_params_cnt.append(link); >>> + } else { >>> + out_params_cnt.append(param_name); >>> } >>> } >>> out_params_cnt.appendTo(this.el); >>> -- >>> 2.5.5 >>> >> ACK > ACK > >>> From a9f7ecf5833db379fe9731184aa4f7aef8845995 Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Tue, 26 Jul 2016 09:48:32 +0200 >>> Subject: [PATCH 10/13] Coverity - iterating over variable which could >>> be null >>> >>> Change condition to check also variable which could be null. >>> --- >>> install/ui/src/freeipa/widgets/APIBrowserWidget.js | 8 ++++---- >>> 1 file changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> index >>> 50c2989fcc126585787df61cdd19493632ed37b9..18773536d3587cdeb9e5fecedcc5e42c05bfe120 >>> 100644 >>> --- a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> +++ b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> @@ -135,7 +135,7 @@ widgets.APIBrowserWidget = declare([Stateful, >>> Evented], { >>> groups = this._get_params(parts[0]); >>> } >>> >>> - if (filter) { >>> + if (filter && groups) { >>> filter = filter.toLowerCase(); >>> var new_groups = []; >>> for (var i=0,l=groups.length; i>> @@ -153,10 +153,10 @@ widgets.APIBrowserWidget = declare([Stateful, >>> Evented], { >>> new_groups.push(groups[i]); >>> } >>> } >>> - return new_groups; >>> - } else { >>> - return groups; >>> + groups = new_groups; >>> } >>> + >>> + return groups; >>> }, >>> >>> /** >>> -- >>> 2.5.5 >>> >> ACK > ACK > >> >>> From 3d63ca1d5cb7a7b84cf20c26d4b1ea5b657c44c4 Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Tue, 26 Jul 2016 12:03:28 +0200 >>> Subject: [PATCH 11/13] Coverity - opens dialog which might not be created >>> >>> Check whether dialog object is created before opening it. >>> --- >>> install/ui/src/freeipa/search.js | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/install/ui/src/freeipa/search.js >>> b/install/ui/src/freeipa/search.js >>> index >>> 25f21e70db170daf0d45a6862ee9adb528ad03bc..fee1bc7523d6afdb3e2b23db2833a415febb85ec >>> 100644 >>> --- a/install/ui/src/freeipa/search.js >>> +++ b/install/ui/src/freeipa/search.js >>> @@ -221,7 +221,7 @@ IPA.search_facet = function(spec, no_init) { >>> that.show_remove_dialog = function() { >>> >>> var dialog = that.create_remove_dialog(); >>> - dialog.open(); >>> + if (dialog) dialog.open(); >>> }; >>> >>> that.find = function() { >>> -- >>> 2.5.5 >>> >> ACK > > ACK but question is whether we should laso log to console that dialog is > not defined because it just hides an issue which may be harder to debug. > It's a good idea, logging added. >>> From 7819293fc546de31cc5eea246242742af3be094e Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Tue, 26 Jul 2016 13:07:30 +0200 >>> Subject: [PATCH 12/13] Coverity - accessing attribute of variable >>> which can >>> point to null >>> >>> Added check whether variable is pointing to null or not. >>> --- >>> install/ui/src/freeipa/widget.js | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/install/ui/src/freeipa/widget.js >>> b/install/ui/src/freeipa/widget.js >>> index >>> 43804c5ea524ca741017d02f6e12ccf60d50b5df..1f61ce7341b1b8e13d4df5acea1f8901a63a290a >>> 100644 >>> --- a/install/ui/src/freeipa/widget.js >>> +++ b/install/ui/src/freeipa/widget.js >>> @@ -4938,7 +4938,7 @@ IPA.combobox_widget = function(spec) { >>> var value = that.list.val(); >>> var option = $('option[value="'+value+'"]', that.list); >>> var next = option.next(); >>> - if (!next.length) return; >>> + if (!next || !next.length) return; >>> that.select(next.val()); >>> }; >>> >>> @@ -4946,7 +4946,7 @@ IPA.combobox_widget = function(spec) { >>> var value = that.list.val(); >>> var option = $('option[value="'+value+'"]', that.list); >>> var prev = option.prev(); >>> - if (!prev.length) return; >>> + if (!prev || !prev.length) return; >>> that.select(prev.val()); >>> }; >>> >>> -- >>> 2.5.5 >>> >> ACK > ACK, but IMO the situation cannot happen. .next() and .prev() should not > return null ever. > There are condition which return null in next() and prev() functions. So, it could happen. >>> From 3ba5110fa8b2255b83fa3e7a4135ec33b85a7fd8 Mon Sep 17 00:00:00 2001 >>> From: Pavel Vomacka >>> Date: Fri, 29 Jul 2016 10:13:21 +0200 >>> Subject: [PATCH 13/13] Coverity - null pointer dereference >>> >>> Add check which protect from calling method of null. >>> --- >>> install/ui/src/freeipa/widgets/APIBrowserWidget.js | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> index >>> 18773536d3587cdeb9e5fecedcc5e42c05bfe120..2164df2f5ffa00edf9ac41fd4cf6254f6d4eb9a3 >>> 100644 >>> --- a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> +++ b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >>> @@ -264,7 +264,7 @@ widgets.APIBrowserWidget = declare([Stateful, >>> Evented], { >>> this.list_w.select(item); >>> >>> // set item >>> - widget.set('item', item); >>> + if (widget) widget.set('item', item); >>> this.set('current', { >>> item: item, >>> type: type, >>> -- >>> 2.5.5 >>> >> ACK >> > Does it fix the issue? There is a line before this one which also uses > `widget` > > if (!widget.el) widget.render(); > > maybe we miss `return;` in: > > } else { > IPA.notify("Invalid type", 'error'); > this.show_default(); > } > > > > > There is another patch, which fixes the line above this one (0089). Or we can add return to the and of else branch. -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0085-Coverity-null-pointer-exception.patch Type: text/x-patch Size: 1042 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0086-Coverity-null-pointer-exception.patch Type: text/x-patch Size: 974 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0087-Coverity-not-initialized-variable.patch Type: text/x-patch Size: 897 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0088-2-Coverity-identical-code-for-different-branches.patch Type: text/x-patch Size: 1437 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0089-Coverity-Accesing-attribute-of-null.patch Type: text/x-patch Size: 1135 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0090-Coverity-removed-dead-code.patch Type: text/x-patch Size: 1370 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0091-2-Coverity-true-branch-can-t-be-executed.patch Type: text/x-patch Size: 1278 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0092-2-Coverity-true-branch-can-t-be-executed.patch Type: text/x-patch Size: 1171 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0093-Coverity-null-pointer-dereference.patch Type: text/x-patch Size: 1406 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0094-Coverity-iterating-over-variable-which-could-be-null.patch Type: text/x-patch Size: 1409 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0095-2-Coverity-opens-dialog-which-might-not-be-created.patch Type: text/x-patch Size: 1031 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0096-Coverity-accessing-attribute-of-variable-which-can-p.patch Type: text/x-patch Size: 1307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0097-Coverity-null-pointer-dereference.patch Type: text/x-patch Size: 1012 bytes Desc: not available URL: From tdudlak at redhat.com Fri Aug 5 12:57:41 2016 From: tdudlak at redhat.com (Tibor Dudlak) Date: Fri, 5 Aug 2016 14:57:41 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate Message-ID: Hi, I have extended my previous patch for authentication with user certificate/smartcard. This patch includes patches and plugin described here: http://www.freeipa.org/page/V4/External_Authentication/Setup Page also contains steps to configure and test this feature. Once this patch is merged and released we will simplify this page to not confuse customers. Addressing ticket: https://fedorahosted.org/freeipa/ticket/5764 Thanks. -- Tibor Dudl?k Intern - Identity management Special Projects Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tdulak-0002-Added-support-for-authentication-with-user-certificate.patch Type: text/x-patch Size: 9918 bytes Desc: not available URL: From abokovoy at redhat.com Fri Aug 5 13:19:37 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Aug 2016 16:19:37 +0300 Subject: [Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate In-Reply-To: References: Message-ID: <20160805131937.5gagch2exgfc2om2@redhat.com> On Fri, 05 Aug 2016, Tibor Dudlak wrote: >Hi, > >I have extended my previous patch for authentication with user >certificate/smartcard. This patch includes patches and plugin described >here: http://www.freeipa.org/page/V4/External_Authentication/Setup >Page also contains steps to configure and test this feature. Once this >patch is merged and released we will simplify this page to not confuse >customers. >Addressing ticket: https://fedorahosted.org/freeipa/ticket/5764 > >Thanks. > >-- >Tibor Dudl?k >Intern - Identity management Special Projects >Red Hat >From e22843f6ab1556528b307951fbcc2476a61a417f Mon Sep 17 00:00:00 2001 >From: Tiboris >Date: Fri, 5 Aug 2016 11:47:06 +0200 >Subject: [PATCH] Added support for authentication with user certificate > >https://fedorahosted.org/freeipa/ticket/5764 >--- > freeipa.spec.in | 5 + > install/conf/ipa.conf | 14 +++ > install/ui/src/freeipa/plugins/cert_auth.js | 179 ++++++++++++++++++++++++++++ > ipaserver/plugins/xmlserver.py | 3 +- > ipaserver/rpcserver.py | 5 + > 5 files changed, 205 insertions(+), 1 deletion(-) > create mode 100644 install/ui/src/freeipa/plugins/cert_auth.js > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index 135e9c980011c6c2730c6c29a3c22098e48270d5..2b95b83613ca3720c95f255f7f64dc029195452c 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -817,6 +817,8 @@ install daemons/dnssec/ipa-ods-exporter %{buildroot}%{_libexecdir}/ipa/ipa-ods-e > > # Web UI plugin dir > mkdir -p %{buildroot}%{_usr}/share/ipa/ui/js/plugins >+mkdir -p %{buildroot}%{_usr}/share/ipa/ui/js/plugins-dist/cert_auth >+install install/ui/src/freeipa/plugins/cert_auth.js %{buildroot}%{_usr}/share/ipa/ui/js/plugins-dist/cert_auth/cert_auth.js > > # DNSSEC config > mkdir -p %{buildroot}%{_sysconfdir}/ipa/dnssec >@@ -1210,6 +1212,9 @@ fi > %{_usr}/share/ipa/ui/js/freeipa/app.js > %{_usr}/share/ipa/ui/js/freeipa/core.js > %dir %{_usr}/share/ipa/ui/js/plugins >+%dir %{_usr}/share/ipa/ui/js/plugins-dist >+%dir %{_usr}/share/ipa/ui/js/plugins-dist/cert_auth >+%{_usr}/share/ipa/ui/js/plugins-dist/cert_auth/cert_auth.js Can you rename plugins-dist to something like 'plugins.d'? This would be more in line with other parts where multiple additions supposed to come and also in line with other projects where a drop-in directory is supported. > %dir %{_usr}/share/ipa/ui/images > %{_usr}/share/ipa/ui/images/*.jpg > %{_usr}/share/ipa/ui/images/*.png >diff --git a/install/conf/ipa.conf b/install/conf/ipa.conf >index 3e7435903b2ad8c4ae5bfc48c0c9fca733757d5d..c37819ff2bd2c045404a383631435ad6c24fdaa3 100644 >--- a/install/conf/ipa.conf >+++ b/install/conf/ipa.conf >@@ -77,6 +77,20 @@ WSGIScriptReloading Off > Header always append Content-Security-Policy "frame-ancestors 'none'" > > >+# Login with user certificate/smartcard configuration >+ >+ AuthType none >+ GssapiCredStore keytab:/etc/httpd/conf/ipa.keytab >+ GssapiCredStore client_keytab:/etc/httpd/conf/ipa.keytab >+ GssapiDelegCcacheDir /var/run/httpd/ipa/clientcaches >+ GssapiImpersonate On >+ NSSVerifyClient require >+ NSSUserName SSL_CLIENT_CERT >+ LookupUserByCertificate On >+ WSGIProcessGroup ipa >+ WSGIApplicationGroup ipa >+ >+ > # Turn off Apache authentication for sessions > > Satisfy Any >diff --git a/install/ui/src/freeipa/plugins/cert_auth.js b/install/ui/src/freeipa/plugins/cert_auth.js >new file mode 100644 >index 0000000000000000000000000000000000000000..282883d6fe82258405afb167dd61b5d6b0f1a7bd >--- /dev/null >+++ b/install/ui/src/freeipa/plugins/cert_auth.js >@@ -0,0 +1,179 @@ >+/* Authors: >+ * Petr Vobornik >+ * Tibor Dudl?k >+ * >+ * Copyright (C) 2016 Red Hat >+ * see file 'COPYING' for use and warranty information >+ * >+ * This program is free software; you can redistribute it and/or modify >+ * it under the terms of the GNU General Public License as published by >+ * the Free Software Foundation, either version 3 of the License, or >+ * (at your option) any later version. >+ * >+ * This program is distributed in the hope that it will be useful, >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >+ * GNU General Public License for more details. >+ * >+ * You should have received a copy of the GNU General Public License >+ * along with this program. If not, see . >+*/ >+/* >+ Plugin to add a button with aside text to FreeiPA login screen >+ >+ Tested against FreeIPA 4.4 >+ >+ Limitation: only one such plugin can be installed - one can override >+ functionality of the other >+ */ >+ >+// we can also depend on other plugin >+define([ >+ 'dojo/Deferred', >+ 'dojo/dom-construct', >+ 'dojo/_base/declare', >+ 'freeipa/jquery', >+ 'freeipa/_base/Spec_mod', >+ 'freeipa/ipa', >+ 'freeipa/auth', >+ 'freeipa/phases', >+ 'freeipa/reg', >+ 'freeipa/plugins/login', >+ 'freeipa/widgets/LoginScreen', >+ ], >+ function(Deferred, construct, declare, $, SpecMod, IPA, auth, phases, >+ reg, mod_login, LoginScreen) { >+ >+ >+var exp = {}; // module object (export) >+ >+exp.CustomLoginScreen = declare([LoginScreen], { >+ >+ crtauth_btn_node: null, >+ >+ auth_failed: "Authentication with personal certificate failed", >+ >+ msg: "

To login with Smart Card," + >+ "please make sure you have valid personal certificate.

", >+ >+ login_url: '/ipa/session/login_x509', >+ >+ render_buttons: function(container) { >+ // add button node to DOM >+ this.crtauth_btn_node = IPA.button({ >+ name: 'crtauth', >+ title:"Login using personal certificate", >+ label: "Smart Card Login", >+ button_class: 'btn btn-link', >+ click: this.crt_login.bind(this) >+ })[0]; >+ >+ // similar to jquery.append(node, container) >+ construct.place(this.crtauth_btn_node, container); >+ construct.place(document.createTextNode(" "), container); >+ >+ // call base class method to create other buttons >+ this.inherited(arguments); >+ }, >+ >+ crt_login: function() { >+ // add custom auth login here >+ this.lookup_credentials().then(function(status) { >+ if (status === 200) { >+ this.emit('logged_in'); >+ } else { >+ var val_summary = this.get_widget('validation'); >+ val_summary.add_error('login', this.auth_failed); >+ } >+ }.bind(this)); >+ }, >+ >+ lookup_credentials: function() { >+ var status; >+ var d = new Deferred(); >+ >+ function error_handler(xhr, text_status, error_thrown) { >+ d.resolve(xhr.status); >+ IPA.hide_activity_icon(); >+ } >+ >+ function success_handler(data, text_status, xhr) { >+ auth.current.set_authenticated(true, 'kerberos'); >+ d.resolve(xhr.status); >+ IPA.hide_activity_icon(); >+ } >+ >+ var request = { >+ url: this.login_url, >+ cache: false, >+ type: "GET", >+ success: success_handler, >+ error: error_handler >+ }; >+ IPA.display_activity_icon(); >+ $.ajax(request); >+ >+ return d.promise; >+ }, >+ >+ show_login_view: function() { >+ >+ this.inherited(arguments); >+ // make sure that crtauth button is also shown when switching from sync form >+ // a bit of hack because, we need to use the exact buttons which were defined >+ // in original LoginScreen -> does't scale if some button is added in later >+ // versions >+ this.set_visible_buttons(['crtauth', 'sync', 'login']); >+ }, >+ >+ set_login_aside_text: function() { >+ // allow to set aside text (the text on right side with help text) >+ >+ // generate original >+ this.inherited(arguments); >+ >+ // add own >+ var aside = this.aside; >+ aside += this.msg; >+ this.set('aside', aside); >+ >+ //alternative solution: >+ // $(this.aside_node).append($("

", { text: "My text"})); >+ } >+}); >+ >+ >+exp.replace_login_screen_spec = function(entity) { >+ >+ var mod = new SpecMod(); >+ >+ var diff = { >+ $replace: [ >+ [ >+ 'widgets', >+ [[{ name: 'login_screen'}, >+ { >+ $type: 'custom_login_screen', >+ name: 'login_screen' >+ }]] >+ ] >+ ] >+ }; >+ mod.mod(mod_login.facet_spec, diff); >+}; >+ >+exp.override = function() { >+ >+ exp.replace_login_screen_spec(); >+}; >+ >+exp.register = function() { >+ var w = reg.widget; >+ w.register('custom_login_screen', exp.CustomLoginScreen ); >+}; >+ >+phases.on('registration', exp.register); >+phases.on('customization', exp.override); >+ >+return exp; >+}); >diff --git a/ipaserver/plugins/xmlserver.py b/ipaserver/plugins/xmlserver.py >index d8fe24e0cb407603e9898e934229c9373f3c8b62..1843c0568543951f2c817616d9e988deaab47056 100644 >--- a/ipaserver/plugins/xmlserver.py >+++ b/ipaserver/plugins/xmlserver.py >@@ -28,12 +28,13 @@ register = Registry() > > > if api.env.context in ('server', 'lite'): >- from ipaserver.rpcserver import wsgi_dispatch, xmlserver, jsonserver_kerb, jsonserver_session, login_kerberos, login_password, change_password, sync_token, xmlserver_session >+ from ipaserver.rpcserver import wsgi_dispatch, xmlserver, jsonserver_kerb, jsonserver_session, login_kerberos, login_x509, login_password, change_password, sync_token, xmlserver_session > register()(wsgi_dispatch) > register()(xmlserver) > register()(jsonserver_kerb) > register()(jsonserver_session) > register()(login_kerberos) >+ register()(login_x509) > register()(login_password) > register()(change_password) > register()(sync_token) >diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py >index d036f3c27521f17709672b830d5aa58167c76b34..a181ecfcb1d01b1c2dd5ee6cb9721d69be8c1863 100644 >--- a/ipaserver/rpcserver.py >+++ b/ipaserver/rpcserver.py >@@ -876,6 +876,11 @@ class login_kerberos(Backend, KerberosSession, HTTP_Status): > > return self.finalize_kerberos_acquisition('login_kerberos', user_ccache_name, environ, start_response) > >+ >+class login_x509(login_kerberos, KerberosSession, HTTP_Status): >+ key = '/session/login_x509' >+ >+ > class login_password(Backend, KerberosSession, HTTP_Status): > > content_type = 'text/plain' >-- >2.7.4 > >-- >Manage your subscription for the Freeipa-devel mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-devel >Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- / Alexander Bokovoy From mbasti at redhat.com Fri Aug 5 13:43:57 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 5 Aug 2016 15:43:57 +0200 Subject: [Freeipa-devel] [Tests][patch-0066] Fixed incorrect domainlevel determination in integration tests In-Reply-To: <57A2EDDA.6040002@redhat.com> References: <57A2EDDA.6040002@redhat.com> Message-ID: On 04.08.2016 09:25, Oleg Fayans wrote: > > > ACK master: * bd5746c538a4e1e7f312de7475eaaa4ce6446cc3 Fixed incorrect domainlevel determination in tests ipa-4-3: * ab29e560bdd03f2bb3742dbd122867979e26f108 Fixed incorrect domainlevel determination in tests -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdudlak at redhat.com Fri Aug 5 13:56:44 2016 From: tdudlak at redhat.com (Tibor Dudlak) Date: Fri, 5 Aug 2016 15:56:44 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate In-Reply-To: <20160805131937.5gagch2exgfc2om2@redhat.com> References: <20160805131937.5gagch2exgfc2om2@redhat.com> Message-ID: Hi Alexander, On Fri, Aug 5, 2016 at 3:19 PM, Alexander Bokovoy wrote: > On Fri, 05 Aug 2016, Tibor Dudlak wrote: > >> Hi, >> >> I have extended my previous patch for authentication with user >> certificate/smartcard. >> ... > > Thanks. >> >> -- >> Tibor Dudl?k >> Intern - Identity management Special Projects >> Red Hat >> >> Can you rename plugins-dist to something like 'plugins.d'? > This would be more in line with other parts where multiple additions > supposed to come and also in line with other projects where a drop-in > directory is supported. > -- > / Alexander Bokovoy > In our case we need to distribute this plugin in such a way that is not enabled by default. In fact something like 'plugins.d' as you wrote already exists ('/usr/share/ipa/ui/js/plugins/'). Main point of creating this new directory is to separate this inactive plugin from plugins located in '/usr/share/ipa/ui/js/plugins/' directory where active plugins are. User can easily enable this plugin, once they desire to enable it, only with creating symlink into this 'plugins' directory. -- Tibor Dudl?k Intern - Identity management Special Projects Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri Aug 5 13:58:13 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 5 Aug 2016 15:58:13 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate In-Reply-To: References: Message-ID: On 08/05/2016 02:57 PM, Tibor Dudlak wrote: > Hi, > > I have extended my previous patch for authentication with user > certificate/smartcard. This patch includes patches and plugin described here: > http://www.freeipa.org/page/V4/External_Authentication/Setup > Page also contains steps to configure and test this feature. Once this patch is > merged and released we will simplify this page to not confuse customers. > Addressing ticket: https://fedorahosted.org/freeipa/ticket/5764 > Let's assume that we will go with this approach and not separate RPM. 1. ipa.conf version needs to be bumped 2. Do not put the web ui plugin in src/freeipa/plugins dir. That is a dir for core UI plugins. This one is sort of hybrid - basically a third party plugin added to core package but enabled as third party because the feature is experimental. Create rather a new dir for that. E.g. plugins.d as Alexander suggested -> freeipa/install/ui/src/plugins.d/cert_auth/cert_auth.js 3. unrelated and "alternative solution" comments needs to be removed from the UI plugin. They were added to the example plugin https://pvoborni.fedorapeople.org/plugins/loginauth/loginauth.js mostly to help you with the development. 4. Add comment to freeipa.spec.in describing what the plugin is and why it is put there this way. 5. The plugin itself deserves better description as well. Right now there is the general description. 6. I have not tried it, but make sure that it passes jslint (`jsl -conf jsl.conf`) Easiest may be to use temp(i.e. do not include it here) jsl.conf e.g.: https://pvoborni.fedorapeople.org/plugins/loginauth/jsl.conf -- Petr Vobornik From mbasti at redhat.com Fri Aug 5 14:44:53 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 5 Aug 2016 16:44:53 +0200 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> <57A0B845.5000105@redhat.com> <02645dd8-7a5d-9201-0a28-498de56dd9ab@redhat.com> Message-ID: <9001af3d-2831-6c3c-141d-941656bcbe94@redhat.com> On 02.08.2016 18:08, Pavel Vomacka wrote: > > On 08/02/2016 05:31 PM, Pavel Vomacka wrote: >> >> >> On 08/02/2016 05:27 PM, Martin Basti wrote: >>> >>> >>> On 02.08.2016 17:12, Rob Crittenden wrote: >>>> Pavel Vomacka wrote: >>>>> Hello, >>>>> >>>>> please review attached patches which Split make lint to more >>>>> targets and >>>>> add jslint >>>> >>>> What's the driver to split the checks out into separate targets? >>> >>> It is called several times during build (makes build slower), and >>> you cannot run `make clean` in case you have wrong API.txt, because >>> it will explode >> Yes, definitely. > So I removed moving the aci and api checks and just add jslint. >>>> >>>> You are moving the makeapi and makeaci from version-update to lint. >>>> They were in version-update for a reason: downstream builds do not >>>> call lint. Downstream may patch code. API cannot break. >>> Can we update downstream spec then? >>> >>>> >>>> No ticket? >>> Pavel please file tickets. >>> >> Yes, I will file tickets for these changes. > Also ticket is now filed: > > https://fedorahosted.org/freeipa/ticket/6161 >>>> >>>> rob >>>> >>> Martin^2 >>> >> > > > ACK 0098-2: works for me Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Aug 5 16:36:34 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 5 Aug 2016 18:36:34 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <57A1E76F.9@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> Message-ID: On 03.08.2016 14:45, Oleg Fayans wrote: > Hi Martin, > > Thanks for the review! Both patches were updated. > > On 07/28/2016 04:11 PM, Martin Basti wrote: >> >> >> On 08.07.2016 15:41, Oleg Fayans wrote: >>> Hi Martin, >>> >>> Thanks for the review! >>> >>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>> >>>> >>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>> Hi guys, >>>>> >>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>> before >>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>> feature. >>>>> >>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>> One more test was added to the patch-0048 >>>>>> >>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>> Fixed a bug in the previous patch, automated 2 more testcases from >>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> IIUC, this will turn off the machine completely, how is cleanup done >>>> then. AFAIK our tests cannot turn on machine again and run >>>> cleanup, so >>>> you will not be able to run more tests on the same topology without >>>> manual cleanup and manual start. >>>> >>>> + replica = self.replicas[0] >>>> + replica.run_command(['poweroff']) >>>> >>>> IMO would be better to just call 'ipactl stop' instead of 'poweroff' >>> >>> Agreed! Fixed. >>> >>>> >>>> Martin^2 >>>> >>> >>> >>> >> *Automated ipa-replica-manage del tests* >> >> 1) >> + replica.run_command(['ipactl', 'stop']) >> + time.sleep(3) >> >> Why do you need sleep here? > > Removed, it was left from the old "poweroff" approach > >> >> >> 2) >> + ruvid_re = re.compile(".*%s:389: (\d+).*" % replica.hostname) >> + replica_ruvs = ruvid_re.findall(result.stdout_text) >> + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', >> + '-p', master.config.dirman_password, >> + replica_ruvs[0]]) >> >> Because you are using re.findall(), without any match you will receive >> IndexError here replica_ruvs[0]. IMO it deserves assert before > > Implemented the assert which checks that the output contains enough > replica RUVs > >> >> 3) >> assert(replica.hostname in result1.stdout_text) >> >> I think that this is error prone. What if there is just error 'could not >> connect to replica ', or something similar. instead of >> listing/cleaning/whatever operation was executed. I think that it should >> be more specific regexp than just finding a replica name substring (Yes >> In IPA we dont always print error so stderr) >> >> I'm not sure, but probably there might be cases when non critical error >> happen and exist status is still 0 > > Agree. Implemented a regex-based search > >> >> 4) >> >> + replica.run_command(['poweroff']) >> + time.sleep(3) >> >> There should not be poweroff, probably sleep could be removed too. > > Gone > >> >> >> * Automated clean-ruv subcommand test* >> >> 1) PEP8, 2 new lines expected >> ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 >> blank lines, found 0 >> ./ipatests/test_integration/test_topology.py:182:80: E501 line too long >> (85 > 79 characters) > > Fixed > >> >> >> 2) >> I dont like doing assert just with count of occurences of substring in >> STDOUT, would be possible to improve this somehow? > > Maybe, but frankly, I don't see how. In this case we are making sure > that both simple and CA-specific RUVs of a replica are displayed. The > format of the output is strict: > Replica Update Vectors: > replica1_hostname:389: RUV_id > replica2_hostname:389: RUV_id > Certificate Server Replica Update Vectors: > replica1_hostname:389: RUV_id > replica2_hostname:389: RUV_id > If we do not see 2 occurrences of the replica hostname than definitely > something went wrong > >> >> 3) >> I'm not sure if clean-ruv is instant operations or there is some magic >> happening in background (we have abort-clean-ruv). Maybe some sleep >> should be there, but this needs investigation. >> >> + assert(replica.hostname in result2.stdout_text), ( >> + "The wrong RUV was deleted") >> + result3 = master.run_command(['ipa-replica-manage', 'list-ruv', >> + '-p', >> master.config.dirman_password]) >> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >> + "CA RUV of the replica is still displayed") >> > > Based on my discussion with Stanislav Laznicka, I understood that by > default clean-ruv does not return the shell until the operation is > finished. You can force dropping into the shell by pressing CTRL+C, in > which case the background job will still be running, but this is not > the default behavior > Test failed: result4 = master.run_command(['ipa-replica-manage', 'list-ruv', '-p', master.config.dirman_password]) > assert(replica.hostname not in result4.stdout_text), ( "replica's RUV is still displayed") E AssertionError: replica's RUV is still displayed E assert 'replica3.ipa.test' not in 'Replica Update V...ipa.test:389: 8\n' E 'replica3.ipa.test' is contained here: E Replica Update Vectors: E \tmaster.ipa.test:389: 4 E \treplica3.ipa.test:389: 3 E \treplica2.ipa.test:389: 7 E Certificate Server Replica Update Vectors: E \tmaster.ipa.test:389: 6 E \treplica2.ipa.test:389: 8 [root at master ~]# ipa topologysegment-find Suffix name: domain ------------------ 2 segments matched ------------------ Segment name: master.ipa.test-to-replica2.ipa.test Left node: master.ipa.test Right node: replica2.ipa.test Connectivity: both Segment name: master.ipa.test-to-replica3.ipa.test Left node: master.ipa.test Right node: replica3.ipa.test Connectivity: both ---------------------------- Number of entries returned 2 ---------------------------- [root at master ~]# ipa-replica-manage list-ruv Directory Manager password: Replica Update Vectors: master.ipa.test:389: 4 replica2.ipa.test:389: 7 replica3.ipa.test:389: 3 Certificate Server Replica Update Vectors: master.ipa.test:389: 6 replica2.ipa.test:389: 8 [root at master ~]# Then I tried manually to clean RUV 3, and it behaves somehow odd [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' '-f' Clean the Replication Update Vector for replica3.ipa.test:389 Background task created to clean replication data. This may take a while. This may be safely interrupted with Ctrl+C Cleanup task created [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors [root at master ~]# ipa-replica-manage list-ruv Directory Manager password: Replica Update Vectors: master.ipa.test:389: 4 replica2.ipa.test:389: 7 replica3.ipa.test:389: 3 Certificate Server Replica Update Vectors: master.ipa.test:389: 6 replica2.ipa.test:389: 8 [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' '-f' Clean the Replication Update Vector for replica3.ipa.test:389 CLEANALLRUV task for replica id 3 already exists. This may be safely interrupted with Ctrl+C Cleanup task created [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 No CLEANALLRUV tasks running No abort CLEANALLRUV tasks running [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' '-f' Clean the Replication Update Vector for replica3.ipa.test:389 Background task created to clean replication data. This may take a while. This may be safely interrupted with Ctrl+C Cleanup task created [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 CLEANALLRUV tasks RID 3: Successfully cleaned rid(3). No abort CLEANALLRUV tasks running [root at master ~]# ipa-replica-manage list-ruv -p Secret123 Replica Update Vectors: master.ipa.test:389: 4 replica2.ipa.test:389: 7 Certificate Server Replica Update Vectors: master.ipa.test:389: 6 replica2.ipa.test:389: 8 I'm not sure if this behavior is right, Ludwig may know. From pvoborni at redhat.com Sat Aug 6 10:32:47 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Sat, 6 Aug 2016 12:32:47 +0200 Subject: [Freeipa-devel] [PATCH] 965 ca-less tests: fix getting cert in pem format from nssdb Message-ID: <6a85a454-b0b0-05b2-8497-9296c08cbea7@redhat.com> usage of ipautil.run in get_pem methond of ca-less tests was not refactored when the ipautil.run was refactored in 099cf98307d4b2f0ace5d5e28754f264808bf59d This results in failure of all CA-less test (probably). Patch is untested though. https://fedorahosted.org/freeipa/ticket/6177 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0965-ca-less-tests-fix-getting-cert-in-pem-format-from-ns.patch Type: text/x-patch Size: 1337 bytes Desc: not available URL: From pvoborni at redhat.com Sat Aug 6 11:16:58 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Sat, 6 Aug 2016 13:16:58 +0200 Subject: [Freeipa-devel] [PATCH] 965 ca-less tests: fix getting cert in pem format from nssdb In-Reply-To: <6a85a454-b0b0-05b2-8497-9296c08cbea7@redhat.com> References: <6a85a454-b0b0-05b2-8497-9296c08cbea7@redhat.com> Message-ID: <9264a4ac-c8b0-a105-815c-f35e4f9fffcf@redhat.com> On 08/06/2016 12:32 PM, Petr Vobornik wrote: > usage of ipautil.run in get_pem methond of ca-less tests was not > refactored when the ipautil.run was refactored in > 099cf98307d4b2f0ace5d5e28754f264808bf59d > > This results in failure of all CA-less test (probably). > > Patch is untested though. > > https://fedorahosted.org/freeipa/ticket/6177 > Original patch doesn't fix the issue. Main culprit is that output is captured only if capture_output=True is passed to ipautil.run Previous patch therefore just replaced old usage to new usage. Attaching fixed path. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0965-1-ca-less-tests-fix-getting-cert-in-pem-format-from-ns.patch Type: text/x-patch Size: 1391 bytes Desc: not available URL: From ftweedal at redhat.com Mon Aug 8 04:34:24 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 8 Aug 2016 14:34:24 +1000 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file Message-ID: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> Please review the attached patch with adds --certificate-out and --certificate-chain-out options to `ca-show' command. Note that --certificate-chain-out currently writes a bogus file due to a bug in Dogtag that will be fixed in this week's build. https://fedorahosted.org/freeipa/ticket/6178 Thanks, Fraser -------------- next part -------------- From 6d3a153a954ab09022af6073ae9ea68668716618 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 8 Aug 2016 14:27:20 +1000 Subject: [PATCH] Add options to write lightweight CA cert or chain to file Administrators need a way to retrieve the certificate or certificate chain of an IPA-managed lightweight CA. Add --certificate-out and --certificate-chain-out options to the `ca-show` command. Fixes: https://fedorahosted.org/freeipa/ticket/6178 --- API.txt | 4 +++- VERSION | 4 ++-- ipaclient/plugins/ca.py | 40 ++++++++++++++++++++++++++++++++++++++++ ipaserver/plugins/ca.py | 23 +++++++++++++++++++++-- ipaserver/plugins/dogtag.py | 12 ++++++++++++ 5 files changed, 78 insertions(+), 5 deletions(-) create mode 100644 ipaclient/plugins/ca.py diff --git a/API.txt b/API.txt index 535d8ec9a4990395207e2455a09a8c1bdef5529a..6ed8c5348876aa6ce1ab5d11e14dbcb1e7cee768 100644 --- a/API.txt +++ b/API.txt @@ -505,9 +505,11 @@ output: Entry('result') output: Output('summary', type=[, ]) output: PrimaryKey('value') command: ca_show/1 -args: 1,4,3 +args: 1,6,3 arg: Str('cn', cli_name='name') option: Flag('all', autofill=True, cli_name='all', default=False) +option: Str('certificate_chain_out?') +option: Str('certificate_out?') option: Flag('raw', autofill=True, cli_name='raw', default=False) option: Flag('rights', autofill=True, default=False) option: Str('version?') diff --git a/VERSION b/VERSION index ca489965050f32d2d8987dfd251ec2b2a0ba1768..3cdb27b806013be2cb0b8b2132c99302865e6358 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=211 -# Last change: mbabinsk: allow 'value' output param in commands without primary key +IPA_API_VERSION_MINOR=212 +# Last change: ftweedal: ca: add options to write cert or cert chain to file diff --git a/ipaclient/plugins/ca.py b/ipaclient/plugins/ca.py new file mode 100644 index 0000000000000000000000000000000000000000..1f4a7c6074b5eb139e01ba2963bf46399ce6d645 --- /dev/null +++ b/ipaclient/plugins/ca.py @@ -0,0 +1,40 @@ +# +# Copyright (C) 2016 FreeIPA Contributors see COPYING for license +# + +from ipaclient.frontend import MethodOverride +from ipalib import util +from ipalib.plugable import Registry +from ipalib.text import _ + +register = Registry() + + + at register(override=True, no_fail=True) +class ca_show(MethodOverride): + def forward(self, *keys, **options): + if 'certificate_out' in options: + util.check_writable_file(options['certificate_out']) + if 'certificate_chain_out' in options: + util.check_writable_file(options['certificate_chain_out']) + + result = super(ca_show, self).forward(*keys, **options) + summaries = [] + if 'certificate_out' in options and 'certificate' in result['result']: + with open(options['certificate_out'], 'wb') as f: + f.write(result['result'].pop('certificate')) + summaries.append ( + _("Certificate written to file '%(file)s'") + % dict(file=options['certificate_out']) + ) + if 'certificate_chain_out' in options and 'chain' in result['result']: + with open(options['certificate_chain_out'], 'wb') as f: + f.write(result['result'].pop('chain')) + summaries.append ( + _("Certificate chain written to file '%(file)s'") + % dict(file=options['certificate_chain_out']) + ) + if len(summaries) > 0: + result['summary'] = '\n'.join(summaries) + + return result diff --git a/ipaserver/plugins/ca.py b/ipaserver/plugins/ca.py index 966ae2b1bdb4bb0207dfa58f0e9c951bc930f766..70aaca19dbece452c8e679a58ce3754ea75666c5 100644 --- a/ipaserver/plugins/ca.py +++ b/ipaserver/plugins/ca.py @@ -140,9 +140,28 @@ class ca_find(LDAPSearch): class ca_show(LDAPRetrieve): __doc__ = _("Display the properties of a CA.") - def execute(self, *args, **kwargs): + takes_options = LDAPRetrieve.takes_options + ( + Str('certificate_out?', + doc=_('Write certificate to file'), + ), + Str('certificate_chain_out?', + doc=_('Write PKCS #7 certificate chain to file'), + ), + ) + + def execute(self, *keys, **options): ca_enabled_check() - return super(ca_show, self).execute(*args, **kwargs) + result = super(ca_show, self).execute(*keys, **options) + + ca_id = result['result']['ipacaid'][0] + if 'certificate_out' in options: + with self.api.Backend.ra_lightweight_ca as ca_api: + result['result']['certificate'] = ca_api.read_ca_cert(ca_id) + if 'certificate_chain_out' in options: + with self.api.Backend.ra_lightweight_ca as ca_api: + result['result']['chain'] = ca_api.read_ca_chain(ca_id) + + return result @register() diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index aef1e888eb1b6c273c1fd12cbf4912407f8f8132..ea78f4ee93d3bd16a2088cf82618e72a9dcf9268 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -2205,6 +2205,18 @@ class ra_lightweight_ca(RestClient): except: raise errors.RemoteRetrieveError(reason=_("Response from CA was not valid JSON")) + def read_ca_cert(self, ca_id): + status, resp_headers, resp_body = self._ssldo( + 'GET', '{}/cert'.format(ca_id), + headers={'Accept': 'application/x-pem-file'}) + return resp_body + + def read_ca_chain(self, ca_id): + status, resp_headers, resp_body = self._ssldo( + 'GET', '{}/chain'.format(ca_id), + headers={'Accept': 'application/x-pem-file'}) + return resp_body + def disable_ca(self, ca_id): self._ssldo( 'POST', ca_id + '/disable', -- 2.5.5 From ldoudova at redhat.com Mon Aug 8 06:18:21 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 8 Aug 2016 08:18:21 +0200 Subject: [Freeipa-devel] [PATCH] 0002 New User Role Tests In-Reply-To: <1797731925.7831984.1469028660649.JavaMail.zimbra@redhat.com> References: <1698677244.50966760.1462789150686.JavaMail.zimbra@redhat.com> <19bc3a86-8e60-f023-6bab-b807a3d03364@redhat.com> <651798515.57202911.1464860977307.JavaMail.zimbra@redhat.com> <479389298.57290567.1464876990869.JavaMail.zimbra@redhat.com> <8b36b91f-b93d-c1d8-0bab-7022b7f29949@redhat.com> <1797731925.7831984.1469028660649.JavaMail.zimbra@redhat.com> Message-ID: <62b8d604-c499-f411-a8a5-6b1eb61edf45@redhat.com> On 07/20/2016 05:31 PM, Peter Lacko wrote: > Sorry for late reply, I was waiting how the discussion with tracker improvement will end, but since there's no progress and I'm leaving soon, I'm attaching new patch. I also created mapping between old and new tests [1], to make life of reviewer easier. Number in first column denotes line number in original file, followed by line number in new tests file and its name. Tests that are not mentioned in there extend previous coverage. > > Regards, > Peter > > [1] http://etherpad.corp.redhat.com/Vk3tRLaPSK Hi, review notes: 1) code related: * leftover PEP8 error: ./ipatests/test_xmlrpc/test_role_plugin.py:696:1: W391 blank line at end of file * in PrivilegeTracker: o creating privilege with description does not work properly, since there's a hardcoded value in track_create method o the check_retrieve method expects 'description' to be returned only when privilege is member of a role, but to the extent of my knowledge that value is returned always * in RoleTracker: o global variable 'member_types' is used only inside the class, so it should be a class variable rather than global o 'check_add_duplicate_member' method uses oneliner to create basis of expected value - suggest to use this more in other methods that do it 'literally' (e.g. check_add_member) o 'update_tracker' method - the main else statement should be investigated more, I'm not sure the try-except part is valid (if I expect the tracker to delete an attribute, but that attribute is not present, it's a pass? Doesn't sound right.) o 'update' method is needlessly simple - look at the same method in BaseTracker, which contains more method calls. Result of the simplicity is that in actual role tests, these other methods like 'check_update' etc. are called outside the 'update' method, when they can just as well be part of the method and save repeating same code over and over. This goes for 'retrieve' and 'find' methods as well. * in role tests (ipatests/test_xmlrpc/test_role_plugin.py): o in class TestDeleredRole, there's unused method setUpClass 2) other: * I strongly suggest to go through all documentation comments, since some of them are vague, or even straight misleading (e.g. in RoleTracker, method 'find_tracker_roles': comment says, that it performs find command, but nothing like that happens!) * similarly as in previous note, please go through all parameter descriptions in the documentation - e.g. in RoleTracker, method 'update_tracker': ":param expected_updates: Dictionary of other attributes" - such description is quite unsatisfactory) * when doing previous two, there are some typos that could be eliminated * some test cases in ipatests/test_xmlrpc/test_role_plugin.py seem incorrectly classified, e.g. method 'test_create_invalid' verifying attempt to create role with invalid name in TestNonexistentRole class that performes operations like role-show, role-delete on nonexistent entries * for future patches, it might be nice to have separate patches for each tracker and the tests Also, since the author Peter Lacko left the company, fixing this patch will be a task for Ganna. Lenka > > > ----- Original Message ----- > From: "Martin Basti" > To: "Peter Lacko" > Cc: freeipa-devel at redhat.com > Sent: Monday, June 6, 2016 12:29:29 PM > Subject: Re: [Freeipa-devel] [PATCH] 0002 New User Role Tests > > > > On 02.06.2016 16:16, Peter Lacko wrote: >> Rebased with updated tests. >> >> Peter >> >> ----- Original Message ----- >> From: "Martin Basti" >> To: "Peter Lacko" >> Cc: freeipa-devel at redhat.com >> Sent: Thursday, June 2, 2016 1:50:06 PM >> Subject: Re: [Freeipa-devel] [PATCH] 0002 New User Role Tests >> >> Your patch doesn't apply anymore on master, there were changes in role >> test and patch have to be updated and rebased >> >> Please look at this for new changes in test_role_plugin.py >> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=5f42b42bd4557a669ab5cfcf1af6596f1a2535f1 >> >> Martin^2 >> >> >> On 02.06.2016 11:49, Peter Lacko wrote: >>> Sorry for late response, I wasn't working these days. >>> Fixed patch is in attachment. >>> >>> Peter >>> >>> >>> ----- Original Message ----- >>> From: "Martin Basti" >>> To: "Peter Lacko" , freeipa-devel at redhat.com >>> Sent: Monday, May 9, 2016 1:06:08 PM >>> Subject: Re: [Freeipa-devel] [PATCH] 0002 New User Role Tests >>> >>> >>> >>> On 09.05.2016 13:04, Martin Basti wrote: >>>> On 09.05.2016 12:19, Peter Lacko wrote: >>>>> +# pylint: disable=unicode-builtin >>>> I'm not doing complete review, just the line above hit my eyes. >>>> >>>> unicode() is not in Py3 because all strings there are unicode, thus >>>> you cannot use it directly, you need something like >>>> >>>> if six.PY2: >>>> str = unicode >>>> >>>> and use str() everywhere and remove that #pylint line >>>> >>>> FYI all enabled pylint checks are there for a good reason, be careful >>>> with disabling it (mainly disabling it for a whole module) rather ask >>>> before if you are not sure. >>>> >>>> Martin^2 >>>> >>> Nope, sorry, I temporarily forgot how to python >>> >>> instead of pylint disable use this >>> >>> if six.PY3: >>> unicode =str >>> >>> and keep unicode there. Sorry >>> >>> Martin^2 > Hi, > > I don't have time to continue with full review, maybe somebody else can > continue instead of me, but anyway NACK, because using str(unicode()) or > unicode(str()) is bad in both ways, it should be just unicode() in case > of strings (with correct mapping unicode=str in Py3). I just I noticed > this by reading code, but I didn't do deeper review, so there might be > more mistakes. > > Martin^2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Aug 8 06:54:05 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 8 Aug 2016 08:54:05 +0200 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> Message-ID: <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> Hi, On 8.8.2016 06:34, Fraser Tweedale wrote: > Please review the attached patch with adds --certificate-out and > --certificate-chain-out options to `ca-show' command. > > Note that --certificate-chain-out currently writes a bogus file due > to a bug in Dogtag that will be fixed in this week's build. > > https://fedorahosted.org/freeipa/ticket/6178 1) The client-side *-out options should be defined on the client side, not on the server side. 2) I don't think there should be additional information included in summary (and it definitely should not be multi-line). I would rather inform the user via an error message when unable to write the files. If you think there is an actual value in informing the user about successfully writing the files, please use ipalib.messages for the job. 3) IMO a better format for the certificate chain than PKCS#7 would be concatenated PEM, as that's the most commonly used format in IPA (in installers, there are no cert chains in API commands ATM). 4) Over the wire, the certs should be DER-formatted, as that's the most common wire format in other API commands. 5) What is the benefit in having the CA cert and the rest of the chain separate? For end-entity certs it makes sense to separate the cert from the CA chain, but for CA certs, you usually want the full chain, no? > > Thanks, > Fraser > > > Honza -- Jan Cholasta From ftweedal at redhat.com Mon Aug 8 07:06:52 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 8 Aug 2016 17:06:52 +1000 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> Message-ID: <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > Hi, > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > Please review the attached patch with adds --certificate-out and > > --certificate-chain-out options to `ca-show' command. > > > > Note that --certificate-chain-out currently writes a bogus file due > > to a bug in Dogtag that will be fixed in this week's build. > > > > https://fedorahosted.org/freeipa/ticket/6178 > > 1) The client-side *-out options should be defined on the client side, not > on the server side. > Will option defined on client side be propagated to, and observable in the ipaserver plugin? The ipaserver plugin needs to observe that *-out has been requested and executes additional command(s) on that basis. > > 2) I don't think there should be additional information included in summary > (and it definitely should not be multi-line). I would rather inform the user > via an error message when unable to write the files. > I was just following the pattern of other commands that write certs, profile config, etc. Apart from consistency with other commands I agree that there is no need to have it. So I will remove it. > If you think there is an actual value in informing the user about > successfully writing the files, please use ipalib.messages for the job. > > > 3) IMO a better format for the certificate chain than PKCS#7 would be > concatenated PEM, as that's the most commonly used format in IPA (in > installers, there are no cert chains in API commands ATM). > Sure, but the main use case isn't IPA. Other apps require PKCS #7 or concatenated PEMs, but sometimes they must be concatenated forward, and othertimes backwards. There is no one size fits all. We can add an option to control the format later, but for now, Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst case is an admin has to invoke `openssl pkcs7' and concat the certs themselves. > > 4) Over the wire, the certs should be DER-formatted, as that's the most > common wire format in other API commands. > OK. > > 5) What is the benefit in having the CA cert and the rest of the chain > separate? For end-entity certs it makes sense to separate the cert from the > CA chain, but for CA certs, you usually want the full chain, no? > If you want to anchor trust directly at a subca (e.g. restrict VPN login to certs issued by VPN sub-CA) then you often just want the cert. The chain option does subsume it, at cost of more work for administrators with this use case. I think it makes sense to keep both options. Will cut a new patch tomorrow. Thanks, Fraser From abokovoy at redhat.com Mon Aug 8 07:24:50 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 10:24:50 +0300 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> Message-ID: <20160808072450.hpybchztz5bak4dx@redhat.com> On Mon, 08 Aug 2016, Fraser Tweedale wrote: >On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: >> Hi, >> >> On 8.8.2016 06:34, Fraser Tweedale wrote: >> > Please review the attached patch with adds --certificate-out and >> > --certificate-chain-out options to `ca-show' command. >> > >> > Note that --certificate-chain-out currently writes a bogus file due >> > to a bug in Dogtag that will be fixed in this week's build. >> > >> > https://fedorahosted.org/freeipa/ticket/6178 >> >> 1) The client-side *-out options should be defined on the client side, not >> on the server side. >> >Will option defined on client side be propagated to, and observable >in the ipaserver plugin? The ipaserver plugin needs to observe that >*-out has been requested and executes additional command(s) on that >basis. You define Str() 'out' option on the server side -- this is what server side will see if --out option would be specified on the client side. Then on the client side you would override forward() method and check if 'out' is in options, then do write to the file. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Aug 8 07:34:57 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 10:34:57 +0300 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map Message-ID: <20160808073457.vrcrunrodu5px433@redhat.com> When SSSD resolves AD users on behalf of slapi-nis, it can accept any user identifier, including user principal name (UPN) which may be different than the canonical user name which SSSD returns. As result, the entry created by slapi-nis will be using canonical user name but the filter for search will refer to the original (aliased) name. The search will not match the newly created entry. The issue is fixed in slapi-nis-0.56.1 by returning two values for 'uid' attribute: the canonical one and the aliased one. This way the search will match. Standard LDAP schema allows multiple values for 'uid' attribute. We actually use the same trick for 'cn' attribute in the groups map already. https://fedorahosted.org/freeipa/ticket/6138 -- / Alexander Bokovoy -------------- next part -------------- From 359328c45465c25a2c34629511bf30097b0b8b0a Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 4 Aug 2016 09:58:50 +0300 Subject: support multiple uid values in schema compatibility tree When SSSD resolves AD users on behalf of slapi-nis, it can accept any user identifier, including user principal name (UPN) which may be different than the canonical user name which SSSD returns. As result, the entry created by slapi-nis will be using canonical user name but the filter for search will refer to the original (aliased) name. The search will not match the newly created entry. The issue is fixed in slapi-nis-0.56.1 by returning two values for 'uid' attribute: the canonical one and the aliased one. This way the search will match. Standard LDAP schema allows multiple values for 'uid' attribute. https://fedorahosted.org/freeipa/ticket/6138 --- install/updates/10-schema_compat.update | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/install/updates/10-schema_compat.update b/install/updates/10-schema_compat.update index e4c257d..fbe8703 100644 --- a/install/updates/10-schema_compat.update +++ b/install/updates/10-schema_compat.update @@ -87,3 +87,7 @@ add:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","objectc add:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","") add:schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} add:schema-compat-entry-attribute: %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") + +dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config +add:schema-compat-entry-attribute: uid=%{uid} +replace:schema-compat-entry-rdn: uid=%{uid}::uid=%first("%{uid}") -- 2.7.4 From mbasti at redhat.com Mon Aug 8 08:18:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 8 Aug 2016 10:18:00 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <20160808073457.vrcrunrodu5px433@redhat.com> References: <20160808073457.vrcrunrodu5px433@redhat.com> Message-ID: On 08.08.2016 09:34, Alexander Bokovoy wrote: > When SSSD resolves AD users on behalf of slapi-nis, it can accept any > user identifier, including user principal name (UPN) which may be > different than the canonical user name which SSSD returns. > > As result, the entry created by slapi-nis will be using canonical user > name but the filter for search will refer to the original (aliased) > name. The search will not match the newly created entry. > > The issue is fixed in slapi-nis-0.56.1 by returning two values for > 'uid' attribute: the canonical one and the aliased one. This way the > search will match. > > Standard LDAP schema allows multiple values for 'uid' attribute. We > actually use the same trick for 'cn' attribute in the groups map > already. > > https://fedorahosted.org/freeipa/ticket/6138 > > > > Hello, should we bump requires to slapi-nis-0.56.1 in freeipa.spec? Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Aug 8 08:30:56 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 8 Aug 2016 10:30:56 +0200 Subject: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate In-Reply-To: References: <1004948019.9643194.1469705403940.JavaMail.zimbra@redhat.com> <11d0579b-2ca2-af88-ed97-2efa477290c0@redhat.com> <529785673.9646711.1469705707399.JavaMail.zimbra@redhat.com> Message-ID: <47d419bd-2b40-8573-2c65-c22a255f5607@redhat.com> On 02.08.2016 14:50, Lenka Doudova wrote: > > > > On 07/29/2016 11:43 AM, Lenka Doudova wrote: >> >> >> >> On 07/29/2016 11:41 AM, Lenka Doudova wrote: >>> >>> On 07/28/2016 01:35 PM, Peter Lacko wrote: >>>> Hops, fixed. >>>> >>>> Peter >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Lenka Doudova" >>>> To:freeipa-devel at redhat.com >>>> Sent: Thursday, July 28, 2016 1:32:25 PM >>>> Subject: Re: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate >>>> >>>> Hi, >>>> >>>> I cannot find any attached patch :) >>>> >>>> Lenka >>>> >>>> >>>> On 07/28/2016 01:30 PM, Peter Lacko wrote: >>>>> Attached you can find a patch adding test for URIs in generated certificate >>>>> ipatests/test_xmlrpc/test_cert_plugin.py >>>>> Since I'm leaving Red Hat in end of July, I won't be able to modify this patch anymore. >>>>> >>>>> Regards, >>>>> >>>>> Peter >>>>> >>>> >>>> >>> Hi, >>> >>> NACK. Code looks fine and works well on master branch, but patch >>> does not apply on 4-3 and 4-2 branches. >>> Peter left the company but claimed he can fix the patch if >>> necessary, I'll communicate it with him or fix it myself. >>> >>> Lenka >>> >>> >> Oh, and forgot this one - PEP8 error: >> ./ipatests/test_xmlrpc/test_cert_plugin.py:191:80: E501 line too long >> (105 > 79 characters) >> >> Lenka >> >> > Hi, > > since Peter has quit already, I took it upon myself to do minor fix > and rebase to the patch. > 1) i removed pylint disable comments from the patch, as they were > unnecessary (this also solved PEP8 error) > 2) I rebased the patch to be applicable for ipa-4-3 branch. > Original functionality of the patch remains unchanged. > > Both fixed patches attached. > > Lenka > > Hello, 1) This is not needed + global sn + + result = api.Command.cert_show(sn, out=unicode(self.certfile)) you need the global statement only for write access. But sn is not assigned in this code block. 2) I prefer to use instance attributes (self.sn) instead of global variables Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Aug 8 08:35:18 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 11:35:18 +0300 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: References: <20160808073457.vrcrunrodu5px433@redhat.com> Message-ID: <20160808083518.x2ose47ttuotcdsy@redhat.com> On Mon, 08 Aug 2016, Martin Basti wrote: > > >On 08.08.2016 09:34, Alexander Bokovoy wrote: >>When SSSD resolves AD users on behalf of slapi-nis, it can accept any >>user identifier, including user principal name (UPN) which may be >>different than the canonical user name which SSSD returns. >> >>As result, the entry created by slapi-nis will be using canonical user >>name but the filter for search will refer to the original (aliased) >>name. The search will not match the newly created entry. >> >>The issue is fixed in slapi-nis-0.56.1 by returning two values for >>'uid' attribute: the canonical one and the aliased one. This way the >>search will match. >> >>Standard LDAP schema allows multiple values for 'uid' attribute. We >>actually use the same trick for 'cn' attribute in the groups map >>already. >> >>https://fedorahosted.org/freeipa/ticket/6138 >> >> >> >> >Hello, > >should we bump requires to slapi-nis-0.56.1 in freeipa.spec? No, this is not required. In Fedora we'll submit a combined update -- I've built slapi-nis-0.56.1-1 packages for f24, f25, and rawhide already but did not submit a Bodhi request. -- / Alexander Bokovoy From jcholast at redhat.com Mon Aug 8 08:49:27 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 8 Aug 2016 10:49:27 +0200 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> Message-ID: <885c4c72-6e8a-4220-b25e-f577612368d2@redhat.com> On 8.8.2016 09:06, Fraser Tweedale wrote: > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: >> Hi, >> >> On 8.8.2016 06:34, Fraser Tweedale wrote: >>> Please review the attached patch with adds --certificate-out and >>> --certificate-chain-out options to `ca-show' command. >>> >>> Note that --certificate-chain-out currently writes a bogus file due >>> to a bug in Dogtag that will be fixed in this week's build. >>> >>> https://fedorahosted.org/freeipa/ticket/6178 >> >> 1) The client-side *-out options should be defined on the client side, not >> on the server side. >> > Will option defined on client side be propagated to, and observable > in the ipaserver plugin? The ipaserver plugin needs to observe that > *-out has been requested and executes additional command(s) on that > basis. Is there a reason not to *always* return the certs? > >> >> 2) I don't think there should be additional information included in summary >> (and it definitely should not be multi-line). I would rather inform the user >> via an error message when unable to write the files. >> > I was just following the pattern of other commands that write certs, > profile config, etc. Apart from consistency with other commands I > agree that there is no need to have it. So I will remove it. > >> If you think there is an actual value in informing the user about >> successfully writing the files, please use ipalib.messages for the job. >> >> >> 3) IMO a better format for the certificate chain than PKCS#7 would be >> concatenated PEM, as that's the most commonly used format in IPA (in >> installers, there are no cert chains in API commands ATM). >> > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > or concatenated PEMs, but sometimes they must be concatenated > forward, and othertimes backwards. There is no one size fits all. True, which is exactly why I think we should at least be self-consistent and use concatenated PEM (and multi-value DER over the wire). > We can add an option to control the format later, but for now, > Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst > case is an admin has to invoke `openssl pkcs7' and concat the certs > themselves. AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, so I'm afraid the worst case would happen virtually always. > >> >> 4) Over the wire, the certs should be DER-formatted, as that's the most >> common wire format in other API commands. >> > OK. > >> >> 5) What is the benefit in having the CA cert and the rest of the chain >> separate? For end-entity certs it makes sense to separate the cert from the >> CA chain, but for CA certs, you usually want the full chain, no? >> > If you want to anchor trust directly at a subca (e.g. restrict VPN > login to certs issued by VPN sub-CA) then you often just want the > cert. The chain option does subsume it, at cost of more work for > administrators with this use case. I think it makes sense to keep > both options. Does it? From what you described above, you either want just the sub-CA cert, or the full chain including the sub-CA cert, in which case it might make more sense to have a single --out option and a --chain flag. > > Will cut a new patch tomorrow. > > Thanks, > Fraser > -- Jan Cholasta From lslebodn at redhat.com Mon Aug 8 08:51:01 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 8 Aug 2016 10:51:01 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <20160808083518.x2ose47ttuotcdsy@redhat.com> References: <20160808073457.vrcrunrodu5px433@redhat.com> <20160808083518.x2ose47ttuotcdsy@redhat.com> Message-ID: <20160808085100.GD7069@10.4.128.1> On (08/08/16 11:35), Alexander Bokovoy wrote: >On Mon, 08 Aug 2016, Martin Basti wrote: >> >> >> On 08.08.2016 09:34, Alexander Bokovoy wrote: >> > When SSSD resolves AD users on behalf of slapi-nis, it can accept any >> > user identifier, including user principal name (UPN) which may be >> > different than the canonical user name which SSSD returns. >> > >> > As result, the entry created by slapi-nis will be using canonical user >> > name but the filter for search will refer to the original (aliased) >> > name. The search will not match the newly created entry. >> > >> > The issue is fixed in slapi-nis-0.56.1 by returning two values for >> > 'uid' attribute: the canonical one and the aliased one. This way the >> > search will match. >> > >> > Standard LDAP schema allows multiple values for 'uid' attribute. We >> > actually use the same trick for 'cn' attribute in the groups map >> > already. >> > >> > https://fedorahosted.org/freeipa/ticket/6138 >> > >> > >> > >> > >> Hello, >> >> should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >No, this is not required. In Fedora we'll submit a combined update -- >I've built slapi-nis-0.56.1-1 packages for f24, f25, and rawhide already >but did not submit a Bodhi request. > How is combined updated related to requires to slapi-nis-0.56.1? It will not prevent tu update freeipa without new slapi-nis. e.g. dnf update freeipa-server. LS From abokovoy at redhat.com Mon Aug 8 08:56:23 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 11:56:23 +0300 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <20160808085100.GD7069@10.4.128.1> References: <20160808073457.vrcrunrodu5px433@redhat.com> <20160808083518.x2ose47ttuotcdsy@redhat.com> <20160808085100.GD7069@10.4.128.1> Message-ID: <20160808085623.daozgyxrlltzviuu@redhat.com> On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >On (08/08/16 11:35), Alexander Bokovoy wrote: >>On Mon, 08 Aug 2016, Martin Basti wrote: >>> >>> >>> On 08.08.2016 09:34, Alexander Bokovoy wrote: >>> > When SSSD resolves AD users on behalf of slapi-nis, it can accept any >>> > user identifier, including user principal name (UPN) which may be >>> > different than the canonical user name which SSSD returns. >>> > >>> > As result, the entry created by slapi-nis will be using canonical user >>> > name but the filter for search will refer to the original (aliased) >>> > name. The search will not match the newly created entry. >>> > >>> > The issue is fixed in slapi-nis-0.56.1 by returning two values for >>> > 'uid' attribute: the canonical one and the aliased one. This way the >>> > search will match. >>> > >>> > Standard LDAP schema allows multiple values for 'uid' attribute. We >>> > actually use the same trick for 'cn' attribute in the groups map >>> > already. >>> > >>> > https://fedorahosted.org/freeipa/ticket/6138 >>> > >>> > >>> > >>> > >>> Hello, >>> >>> should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>No, this is not required. In Fedora we'll submit a combined update -- >>I've built slapi-nis-0.56.1-1 packages for f24, f25, and rawhide already >>but did not submit a Bodhi request. >> >How is combined updated related to requires to slapi-nis-0.56.1? >It will not prevent tu update freeipa without new slapi-nis. > >e.g. > dnf update freeipa-server. An update file in FreeIPA that is proposed by this patch does not affect operation of the older slapi-nis deployment once update is applied. -- / Alexander Bokovoy From Peter.Marx at knorr-bremse.com Mon Aug 8 09:27:31 2016 From: Peter.Marx at knorr-bremse.com (Marx, Peter) Date: Mon, 8 Aug 2016 09:27:31 +0000 Subject: [Freeipa-devel] certmonger proxy configuration not possible ? In-Reply-To: <20160804160147.2mq54tfooquehlvh@redhat.com> References: <2C720BBFE8885346B9A4377911BABE7886889266@MUCS72046.corp.knorr-bremse.com> <57A1F6EA.9080901@redhat.com> <2C720BBFE8885346B9A4377911BABE788688ADD9@MUCS72046.corp.knorr-bremse.com> <20160804160147.2mq54tfooquehlvh@redhat.com> Message-ID: <2C720BBFE8885346B9A4377911BABE788688CA5F@MUCS72046.corp.knorr-bremse.com> I am trying this but it has no effect - as if the environment is not passed to the called helper scep-submit. In /usr/lib/systemd/certmonger.service there is already a link defined to add stuff: [Service] .. EnvironmentFile=/etc/sysconfig/certmonger In /etc/sysconfig/certmonger I added my proxy like this: [Service] Environment="http_proxy=http://proxyuser:proxypassword at proxyserver:proxyport" After systemctl daemon-reload and systemctl restart certmonger my requests still do not get to the proxy. Commenting out the EnvironmetFile line and adding the Environment line directly in certmonger.service had the same result. Can somebody confirm that the proxy setting is visible to the called scep-submit ? -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Thursday, August 04, 2016 6:02 PM To: Marx, Peter Cc: Rob Crittenden; 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certmonger proxy configuration not possible ? On Thu, 04 Aug 2016, Marx, Peter wrote: >I tried it and found out it can't work this way - when issuing a CSR >with getcert, the parameters of this request are normally handed over >by getcert to the scep-submit helper. I see no way to intercept these >parameters and pass them to the proxy-shellscript. Only the -u >paramter is known beforehand, as it is configured in the ca description >file or in the proxy shellscript itself. On systemd-enabled systems certmonger runs as a service. You can affect the environment of the service by adding files ending in .conf in /etc/systemd/system/certmonger.service.d/ See systemd.service and systemd.unit man pages. > >Peter > >-----Original Message----- >From: Rob Crittenden [mailto:rcritten at redhat.com] >Sent: Wednesday, August 03, 2016 3:52 PM >To: Marx, Peter; 'freeipa-devel at redhat.com' >Subject: Re: [Freeipa-devel] certmonger proxy configuration not possible ? > >Marx, Peter wrote: >> Hi, >> >> i have to access an external PKI server with SCEP protocol through >> our corporate proxy. On command line I can set the proxy and trigger >> a CSR with the scep-submit helper successfully. > >What are you setting, environment variables I assume? > >> But same operation with getcert fails, as there is no proxy >> configuration possibility in e.g. certmonger.conf. >> >> How can I work around this ? > >A quick kludge might be to replace scep-submit with a shell script that exports the proxy config and then calls the real scep-submit. > >A perhaps better and more supportable idea would be to add a CA pointing to this new helper, something like: > >getcert add-ca -c exampleSCEPca -e \ > "/usr/libexec/certmonger/scep-submit-proxy -u http://ca.example.com/cgi-bin/pkiclient.exe" > >So scep-submit-proxy would setup the environment and call scep-submit. > >rob > >> >> Peter >> >> >> >> Knorr-Bremse IT-Services GmbH >> Sitz: M?nchen >> Gesch?ftsf?hrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald >> Schneider Registergericht M?nchen, HR B 167 268 >> >> This transmission is intended solely for the addressee and contains >> confidential information. >> If you are not the intended recipient, please immediately inform the >> sender and delete the message and any attachments from your system. >> Furthermore, please do not copy the message or disclose the contents >> to anyone unless agreed otherwise. To the extent permitted by law we >> shall in no way be liable for any damages, whatever their nature, >> arising out of transmission failures, viruses, external influence, delays and the like. >> >> > > >automechanika - 13.09.-17.09.2016 - Messe Frankfurt - Hall 3.0 - Stand >G98 + E91 InnoTrans - 20.09.-23.09.2016 - Messe Berlin - Hall 1.2b - >Stand 104 + 210 IAA - 22.09.-29.09.2016 - Messe Hannover - Hall 17 - >Stand A30 + D131 > >Knorr-Bremse IT-Services GmbH >Sitz: Muenchen >Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald >Schneider Registergericht Muenchen, HR B 167 268 > >This transmission is intended solely for the addressee and contains confidential information. >If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. >Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. > >-- >Manage your subscription for the Freeipa-devel mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-devel >Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- / Alexander Bokovoy automechanika - 13.09.-17.09.2016 - Messe Frankfurt - Hall 3.0 - Stand G98 + E91 InnoTrans - 20.09.-23.09.2016 - Messe Berlin - Hall 1.2b - Stand 104 + 210 IAA - 22.09.-29.09.2016 - Messe Hannover - Hall 17 - Stand A30 + D131 Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. From abokovoy at redhat.com Mon Aug 8 09:34:59 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 12:34:59 +0300 Subject: [Freeipa-devel] [PATCH 0214] Support schema files for external plugins Message-ID: <20160808093459.ivfpnh5femnqf7mi@redhat.com> Hi! Attached patch is what is needed to allow external plugins for FreeIPA framework to be functional if they need to extend a schema. The idea is that we would have a separate directory as /usr/share/ipa/schema.d and will allow to use schema (*.ldif) files from it and its subdirectories during install and upgrade stages. Without the patch only selected schema files from /usr/share/ipa are used during install and upgrade. This leads to a failure to install IPA server (or upgrade it) if a new plugin is added. If plugin defines managed permissions, upgrade tool will generate ACIs which will fail to be inserted into LDAP store due to references to missing attributes and object classes. The patch adds a directory to be installed and a helper utility that loads files from the directory and adds them to the list of schema files used during update of dsinstance and upgrade of the server. With this patch I'm successfully managed to make FleetCommander integration plugin completely independent of FreeIPA. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Aug 8 09:48:07 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 12:48:07 +0300 Subject: [Freeipa-devel] certmonger proxy configuration not possible ? In-Reply-To: <2C720BBFE8885346B9A4377911BABE788688CA5F@MUCS72046.corp.knorr-bremse.com> References: <2C720BBFE8885346B9A4377911BABE7886889266@MUCS72046.corp.knorr-bremse.com> <57A1F6EA.9080901@redhat.com> <2C720BBFE8885346B9A4377911BABE788688ADD9@MUCS72046.corp.knorr-bremse.com> <20160804160147.2mq54tfooquehlvh@redhat.com> <2C720BBFE8885346B9A4377911BABE788688CA5F@MUCS72046.corp.knorr-bremse.com> Message-ID: <20160808094807.dy2ly5z7uqnnsbxv@redhat.com> On Mon, 08 Aug 2016, Marx, Peter wrote: >I am trying this but it has no effect - as if the environment is not passed to the called helper scep-submit. > >In /usr/lib/systemd/certmonger.service there is already a link defined to add stuff: >[Service] >.. >EnvironmentFile=/etc/sysconfig/certmonger > >In /etc/sysconfig/certmonger I added my proxy like this: > >[Service] >Environment="http_proxy=http://proxyuser:proxypassword at proxyserver:proxyport" > >After systemctl daemon-reload and systemctl restart certmonger my >requests still do not get to the proxy. > >Commenting out the EnvironmetFile line and adding the Environment line >directly in certmonger.service had the same result. > >Can somebody confirm that the proxy setting is visible to the called >scep-submit ? I've checked certmonger source code and while libcurl can be configured to use proxy and proxy authentication, certmonger does not configure it to do so. As result, environmental variables have no influence on the use of libcurl by certmonger. It is worth to open a ticket for certmonger to add proxy support. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Aug 8 10:26:26 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 13:26:26 +0300 Subject: [Freeipa-devel] [PATCH 0214] Support schema files for external plugins In-Reply-To: <20160808093459.ivfpnh5femnqf7mi@redhat.com> References: <20160808093459.ivfpnh5femnqf7mi@redhat.com> Message-ID: <20160808102626.ve3ubsyhjiotpzcp@redhat.com> On Mon, 08 Aug 2016, Alexander Bokovoy wrote: >Hi! > >Attached patch is what is needed to allow external plugins for FreeIPA >framework to be functional if they need to extend a schema. > >The idea is that we would have a separate directory as >/usr/share/ipa/schema.d and will allow to use schema (*.ldif) files from >it and its subdirectories during install and upgrade stages. > >Without the patch only selected schema files from /usr/share/ipa are >used during install and upgrade. This leads to a failure to install IPA >server (or upgrade it) if a new plugin is added. If plugin defines >managed permissions, upgrade tool will generate ACIs which will fail to >be inserted into LDAP store due to references to missing attributes and >object classes. > >The patch adds a directory to be installed and a helper utility that >loads files from the directory and adds them to the list of schema files >used during update of dsinstance and upgrade of the server. > >With this patch I'm successfully managed to make FleetCommander >integration plugin completely independent of FreeIPA. Patch attached now. ;) -- / Alexander Bokovoy -------------- next part -------------- From 045c7b38c387c362358d1ac2aa19a6fe07d18be5 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 5 Aug 2016 13:04:19 +0300 Subject: [PATCH 3/5] support schema files from third-party plugins Allow upgrade process to include schema files from third-party plugins installed in /usr/share/ipa/schema.d/*.schema. The directory /usr/shar/eipa/schema.d is owned by the server-common subpackage and therefore third-party plugins should depend on freeipa-server-common (ipa-server-common) package in their package dependencies. Resolves: https://fedorahosted.org/freeipa/ticket/5864 --- freeipa.spec.in | 5 ++++- install/configure.ac | 1 + install/share/Makefile.am | 1 + install/share/schema.d/Makefile.am | 16 ++++++++++++++++ install/share/schema.d/README | 14 ++++++++++++++ ipaplatform/base/paths.py | 1 + ipaserver/install/dsinstance.py | 15 ++++++++++++++- ipaserver/install/server/upgrade.py | 3 +++ 8 files changed, 54 insertions(+), 2 deletions(-) create mode 100644 install/share/schema.d/Makefile.am create mode 100644 install/share/schema.d/README diff --git a/freeipa.spec.in b/freeipa.spec.in index 135e9c9..8acb3fc 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -871,6 +871,8 @@ mkdir -p %{buildroot}%{_sysconfdir}/cron.d mkdir -p %{buildroot}%{_sysconfdir}/ipa/custodia +mkdir -p %{buildroot}%{_usr}/share/ipa/schema.d + %endif # ONLY_CLIENT @@ -1248,7 +1250,8 @@ fi %ghost %{_localstatedir}/lib/ipa/pki-ca/publish %ghost %{_localstatedir}/named/dyndb-ldap/ipa %dir %attr(0700,root,root) %{_sysconfdir}/ipa/custodia - +%dir %{_usr}/share/ipa/schema.d +%attr(0644,root,root) %{_usr}/share/ipa/schema.d/README %files server-dns %defattr(-,root,root,-) diff --git a/install/configure.ac b/install/configure.ac index b5f77bf..81f17b9 100644 --- a/install/configure.ac +++ b/install/configure.ac @@ -88,6 +88,7 @@ AC_CONFIG_FILES([ share/advise/Makefile share/advise/legacy/Makefile share/profiles/Makefile + share/schema.d/Makefile ui/Makefile ui/css/Makefile ui/src/Makefile diff --git a/install/share/Makefile.am b/install/share/Makefile.am index cd1c164..d8845ee 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -3,6 +3,7 @@ NULL = SUBDIRS = \ advise \ profiles \ + schema.d \ $(NULL) appdir = $(IPA_DATA_DIR) diff --git a/install/share/schema.d/Makefile.am b/install/share/schema.d/Makefile.am new file mode 100644 index 0000000..0fef87f --- /dev/null +++ b/install/share/schema.d/Makefile.am @@ -0,0 +1,16 @@ +NULL = + +SUBDIRS = \ + $(NULL) + +appdir = $(IPA_DATA_DIR)/schema.d +app_DATA = README \ + $(NULL) + +EXTRA_DIST = \ + $(app_DATA) \ + $(NULL) + +MAINTAINERCLEANFILES = \ + *~ \ + Makefile.in diff --git a/install/share/schema.d/README b/install/share/schema.d/README new file mode 100644 index 0000000..19e3e68 --- /dev/null +++ b/install/share/schema.d/README @@ -0,0 +1,14 @@ +This directory is indended to store schema files for 3rd-party plugins. + +Each schema file should be named NN-description.ldif where NN is a number 00..90. + +The schema files from this directory are merged together with the core IPA +schema files during the run of ipa-server-upgrade utility. Therefore, they are +also installed when upgrade happens within the process of ipa-server-install. + +The directory is installed as /usr/share/ipa/schema.d and is owned by a +freeipa-server-common package. Therefore, a 3rd-party plugin would need to +depend on the freeipa-server-common package if it delivers the schema file(s). + +You may place your schema files in a subdirectory too, the code that loads +schema files processes recursively all subdirectories of schema.d. diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index b1fedf5..fff55a3 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -354,6 +354,7 @@ class BasePathNamespace(object): IPA_CUSTODIA_SOCKET = '/run/httpd/ipa-custodia.sock' IPA_CUSTODIA_AUDIT_LOG = '/var/log/ipa-custodia.audit.log' IPA_GETKEYTAB = '/usr/sbin/ipa-getkeytab' + EXTERNAL_SCHEMA_DIR = '/usr/share/ipa/schema.d' @property def USER_CACHE_PATH(self): diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index c93b3b4..4d372ee 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -28,6 +28,7 @@ import re import time import tempfile import stat +import fnmatch import ldap @@ -180,6 +181,16 @@ def get_domain_level(api=api): return int(entry.single_value['ipaDomainLevel']) +def get_all_external_schema_files(root): + """Get all schema files""" + f = [] + for path, subdirs, files in os.walk(root): + for name in files: + if fnmatch.fnmatch(name, "*.ldif"): + f.append(os.path.join(path, name)) + return f + + INF_TEMPLATE = """ [General] FullMachineName= $FQDN @@ -656,7 +667,9 @@ class DsInstance(service.Service): conn.unbind() def apply_updates(self): - data_upgrade = upgradeinstance.IPAUpgrade(self.realm) + schema_files = get_all_external_schema_files(paths.EXTERNAL_SCHEMA_DIR) + data_upgrade = upgradeinstance.IPAUpgrade(self.realm, + schema_files=schema_files) try: data_upgrade.create_instance() except Exception as e: diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index 4342717..2d6b8cb 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1817,6 +1817,9 @@ def upgrade(): realm = api.env.realm schema_files = [os.path.join(ipautil.SHARE_DIR, f) for f in dsinstance.ALL_SCHEMA_FILES] + + schema_files.extend(dsinstance.get_all_external_schema_files( + paths.EXTERNAL_SCHEMA_DIR)) data_upgrade = IPAUpgrade(realm, schema_files=schema_files) try: -- 2.7.4 From pspacek at redhat.com Mon Aug 8 10:28:23 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 8 Aug 2016 12:28:23 +0200 Subject: [Freeipa-devel] [PATCH 0214] Support schema files for external plugins In-Reply-To: <20160808093459.ivfpnh5femnqf7mi@redhat.com> References: <20160808093459.ivfpnh5femnqf7mi@redhat.com> Message-ID: <3cef9c94-5798-24bb-db11-ab5de30eecf5@redhat.com> On 8.8.2016 11:34, Alexander Bokovoy wrote: > Hi! > > Attached patch is what is needed to allow external plugins for FreeIPA > framework to be functional if they need to extend a schema. > > The idea is that we would have a separate directory as > /usr/share/ipa/schema.d and will allow to use schema (*.ldif) files from > it and its subdirectories during install and upgrade stages. > > Without the patch only selected schema files from /usr/share/ipa are > used during install and upgrade. This leads to a failure to install IPA > server (or upgrade it) if a new plugin is added. If plugin defines > managed permissions, upgrade tool will generate ACIs which will fail to > be inserted into LDAP store due to references to missing attributes and > object classes. > > The patch adds a directory to be installed and a helper utility that > loads files from the directory and adds them to the list of schema files > used during update of dsinstance and upgrade of the server. > > With this patch I'm successfully managed to make FleetCommander > integration plugin completely independent of FreeIPA. 1. I cannot see a patch attached to this e-mail :-) 2. Needless to say that ticket in appropriate milestone is going to be required. -- Petr^2 Spacek From abokovoy at redhat.com Mon Aug 8 10:32:46 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 13:32:46 +0300 Subject: [Freeipa-devel] [PATCH 0214] Support schema files for external plugins In-Reply-To: <3cef9c94-5798-24bb-db11-ab5de30eecf5@redhat.com> References: <20160808093459.ivfpnh5femnqf7mi@redhat.com> <3cef9c94-5798-24bb-db11-ab5de30eecf5@redhat.com> Message-ID: <20160808103246.4glj47kgbcnwfgya@redhat.com> On Mon, 08 Aug 2016, Petr Spacek wrote: >On 8.8.2016 11:34, Alexander Bokovoy wrote: >> Hi! >> >> Attached patch is what is needed to allow external plugins for FreeIPA >> framework to be functional if they need to extend a schema. >> >> The idea is that we would have a separate directory as >> /usr/share/ipa/schema.d and will allow to use schema (*.ldif) files from >> it and its subdirectories during install and upgrade stages. >> >> Without the patch only selected schema files from /usr/share/ipa are >> used during install and upgrade. This leads to a failure to install IPA >> server (or upgrade it) if a new plugin is added. If plugin defines >> managed permissions, upgrade tool will generate ACIs which will fail to >> be inserted into LDAP store due to references to missing attributes and >> object classes. >> >> The patch adds a directory to be installed and a helper utility that >> loads files from the directory and adds them to the list of schema files >> used during update of dsinstance and upgrade of the server. >> >> With this patch I'm successfully managed to make FleetCommander >> integration plugin completely independent of FreeIPA. > >1. I cannot see a patch attached to this e-mail :-) See my other email. ;) >2. Needless to say that ticket in appropriate milestone is going to be required. Sure. Moving ticket from one milestone to another is a simple act. I wanted to show that it is actually an almost trivial patch to enable external plugin development and argue by that fact we could have it added, thus raising the ticket to a better milestone. -- / Alexander Bokovoy From pvoborni at redhat.com Mon Aug 8 10:39:03 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 8 Aug 2016 12:39:03 +0200 Subject: [Freeipa-devel] [PATCH 0214] Support schema files for external plugins In-Reply-To: <20160808102626.ve3ubsyhjiotpzcp@redhat.com> References: <20160808093459.ivfpnh5femnqf7mi@redhat.com> <20160808102626.ve3ubsyhjiotpzcp@redhat.com> Message-ID: On 08/08/2016 12:26 PM, Alexander Bokovoy wrote: > On Mon, 08 Aug 2016, Alexander Bokovoy wrote: >> Hi! >> >> Attached patch is what is needed to allow external plugins for FreeIPA >> framework to be functional if they need to extend a schema. >> >> The idea is that we would have a separate directory as >> /usr/share/ipa/schema.d and will allow to use schema (*.ldif) files from >> it and its subdirectories during install and upgrade stages. >> >> Without the patch only selected schema files from /usr/share/ipa are >> used during install and upgrade. This leads to a failure to install IPA >> server (or upgrade it) if a new plugin is added. If plugin defines >> managed permissions, upgrade tool will generate ACIs which will fail to >> be inserted into LDAP store due to references to missing attributes and >> object classes. >> >> The patch adds a directory to be installed and a helper utility that >> loads files from the directory and adds them to the list of schema files >> used during update of dsinstance and upgrade of the server. >> >> With this patch I'm successfully managed to make FleetCommander >> integration plugin completely independent of FreeIPA. > Patch attached now. ;) > I'll assume that we want to target 4.4.x therefore it can be pushed to master, right? I.e. no need for creating ipa-4-4 branch atm. Reasoning is that currently F24 has 4.3.x. F25 will most likely have 4.4.x because 4.5 is still in planning. -- Petr Vobornik From mkosek at redhat.com Mon Aug 8 10:52:33 2016 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 8 Aug 2016 12:52:33 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate In-Reply-To: References: Message-ID: On 08/05/2016 02:57 PM, Tibor Dudlak wrote: > Hi, > > I have extended my previous patch for authentication with user > certificate/smartcard. This patch includes patches and plugin described here: > http://www.freeipa.org/page/V4/External_Authentication/Setup > Page also contains steps to configure and test this feature. Once this patch is > merged and released we will simplify this page to not confuse customers. > Addressing ticket: https://fedorahosted.org/freeipa/ticket/5764 > > Thanks. I discussed this with Jan Pazdziora on IRC, outside of this mail thread, so let me repeat my suggestion here. I still think it is premature to add plugins like that to FreeIPA core git. We are not agreed yet how we will distribute FreeIPA plugins, so I would not rush adding this plugin to FreeIPA core, especially since it is very experimental and not even secure yet. FreeIPA plugin distribution should be more thought through and discussed. As I proposed, this plugin can now live outside of FreeIPA core git, in it's own life cycle (maybe in freeipa-plugins github git repo we create?) so that it can be updated without updating whole FreeIPA core. In this effort, I would suggest to only consider updates of * ipaserver/plugins/xmlserver.py * ipaserver/rpcserver.py as these would have to patched by admin deploying this feature and would be overwritten by RPM updates. The plugin itself or server.conf can be deployed and installed separatenly, even via other RPM. Martin From abokovoy at redhat.com Mon Aug 8 11:12:48 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 14:12:48 +0300 Subject: [Freeipa-devel] [PATCH 0214] Support schema files for external plugins In-Reply-To: References: <20160808093459.ivfpnh5femnqf7mi@redhat.com> <20160808102626.ve3ubsyhjiotpzcp@redhat.com> Message-ID: <20160808111248.3kpuzprcwxksfmgr@redhat.com> On Mon, 08 Aug 2016, Petr Vobornik wrote: >On 08/08/2016 12:26 PM, Alexander Bokovoy wrote: >> On Mon, 08 Aug 2016, Alexander Bokovoy wrote: >>> Hi! >>> >>> Attached patch is what is needed to allow external plugins for FreeIPA >>> framework to be functional if they need to extend a schema. >>> >>> The idea is that we would have a separate directory as >>> /usr/share/ipa/schema.d and will allow to use schema (*.ldif) files from >>> it and its subdirectories during install and upgrade stages. >>> >>> Without the patch only selected schema files from /usr/share/ipa are >>> used during install and upgrade. This leads to a failure to install IPA >>> server (or upgrade it) if a new plugin is added. If plugin defines >>> managed permissions, upgrade tool will generate ACIs which will fail to >>> be inserted into LDAP store due to references to missing attributes and >>> object classes. >>> >>> The patch adds a directory to be installed and a helper utility that >>> loads files from the directory and adds them to the list of schema files >>> used during update of dsinstance and upgrade of the server. >>> >>> With this patch I'm successfully managed to make FleetCommander >>> integration plugin completely independent of FreeIPA. >> Patch attached now. ;) >> > >I'll assume that we want to target 4.4.x therefore it can be pushed to >master, right? I.e. no need for creating ipa-4-4 branch atm. Right. >Reasoning is that currently F24 has 4.3.x. F25 will most likely have >4.4.x because 4.5 is still in planning. Sounds good to me. FleetCommander (which is one of drivers behind the patches) is targeting F25 as well. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Aug 8 11:13:21 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 14:13:21 +0300 Subject: [Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate In-Reply-To: References: Message-ID: <20160808111321.jc2wvakxw477y4vv@redhat.com> On Mon, 08 Aug 2016, Martin Kosek wrote: >On 08/05/2016 02:57 PM, Tibor Dudlak wrote: >> Hi, >> >> I have extended my previous patch for authentication with user >> certificate/smartcard. This patch includes patches and plugin described here: >> http://www.freeipa.org/page/V4/External_Authentication/Setup >> Page also contains steps to configure and test this feature. Once this patch is >> merged and released we will simplify this page to not confuse customers. >> Addressing ticket: https://fedorahosted.org/freeipa/ticket/5764 >> >> Thanks. > >I discussed this with Jan Pazdziora on IRC, outside of this mail thread, so let >me repeat my suggestion here. I still think it is premature to add plugins like >that to FreeIPA core git. We are not agreed yet how we will distribute FreeIPA >plugins, so I would not rush adding this plugin to FreeIPA core, especially >since it is very experimental and not even secure yet. FreeIPA plugin >distribution should be more thought through and discussed. > >As I proposed, this plugin can now live outside of FreeIPA core git, in it's >own life cycle (maybe in freeipa-plugins github git repo we create?) so that it >can be updated without updating whole FreeIPA core. In this effort, I would >suggest to only consider updates of > >* ipaserver/plugins/xmlserver.py >* ipaserver/rpcserver.py > >as these would have to patched by admin deploying this feature and would be >overwritten by RPM updates. The plugin itself or server.conf can be deployed >and installed separatenly, even via other RPM. Right. This was my thinking too when I saw the patches. -- / Alexander Bokovoy From tbordaz at redhat.com Mon Aug 8 11:15:00 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 8 Aug 2016 13:15:00 +0200 Subject: [Freeipa-devel] [PATCH 0196] baseldap: Fix MidairCollision instantiation during entry modification In-Reply-To: <57A4797D.2070501@redhat.com> References: <20160726152219.u67pdvfxg4mwkogc@redhat.com> <57A4797D.2070501@redhat.com> Message-ID: <57A869B4.8000402@redhat.com> On 08/05/2016 01:33 PM, thierry bordaz wrote: > > > On 07/26/2016 05:22 PM, Alexander Bokovoy wrote: >> On Tue, 26 Jul 2016, Martin Babinsky wrote: >>> Fix for https://fedorahosted.org/freeipa/ticket/6097 >>> >>> Since this issue was found during investigation of other ticket[1], >>> you can test it by performing steps to reproduce #6041, but instead >>> of internal error you should see the MidairCollision raised as >>> public error with the right error message. >>> >>> [1] https://fedorahosted.org/freeipa/ticket/6041 >> I have a preliminary patch for slapi-nis to fix 6041 (attached). > > The slapi-nis patch looks good to me. > Ludwig may give the final ACK. > > thanks > thierry The fix for https://fedorahosted.org/freeipa/ticket/6041 is good. ACK thierry >> >> As for this fix -- ACK. >> >>> >>> -- >>> Martin^3 Babinsky >> >>> From 8f0d6dab08f61fe2fd1ad64a63f7ab91fc5227d4 Mon Sep 17 00:00:00 2001 >>> From: Martin Babinsky >>> Date: Mon, 25 Jul 2016 14:05:08 +0200 >>> Subject: [PATCH] baseldap: Fix MidairCollision instantiation during >>> entry >>> modification >>> >>> https://fedorahosted.org/freeipa/ticket/6097 >>> --- >>> ipaserver/plugins/baseldap.py | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/ipaserver/plugins/baseldap.py >>> b/ipaserver/plugins/baseldap.py >>> index >>> 6107e43a6ee17d9b9a63d9dc109664d8b232069f..f7844e3e7c59c259b9c8367d135b2dbefc3f0016 >>> 100644 >>> --- a/ipaserver/plugins/baseldap.py >>> +++ b/ipaserver/plugins/baseldap.py >>> @@ -1466,7 +1466,7 @@ class LDAPUpdate(LDAPQuery, crud.Update): >>> entry_attrs.dn, attrs_list) >>> except errors.NotFound: >>> raise errors.MidairCollision( >>> - format=_('the entry was deleted while being modified') >>> + message=_('the entry was deleted while being >>> modified') >>> ) >>> >>> self.obj.get_indirect_members(entry_attrs, attrs_list) >>> @@ -2344,7 +2344,7 @@ class BaseLDAPModAttribute(LDAPQuery): >>> entry_attrs.dn, attrs_list) >>> except errors.NotFound: >>> raise errors.MidairCollision( >>> - format=_('the entry was deleted while being modified') >>> + message=_('the entry was deleted while being >>> modified') >>> ) >>> >>> for callback in self.get_callbacks('post'): >>> -- >>> 2.7.4 >>> >> >>> -- >>> Manage your subscription for the Freeipa-devel mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code >> >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Aug 8 11:22:08 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 8 Aug 2016 13:22:08 +0200 Subject: [Freeipa-devel] [PATCH 0154] client: RPM require initscripts to get *-domainname.service Message-ID: <6b6bb9c3-9ac9-27c7-9e4c-3e637cab6744@redhat.com> Hello, client: RPM require initscripts to get *-domainname.service https://fedorahosted.org/freeipa/ticket/4831 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0154-client-RPM-require-initscripts-to-get-domainname.ser.patch Type: text/x-patch Size: 817 bytes Desc: not available URL: From jcholast at redhat.com Mon Aug 8 11:26:19 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 8 Aug 2016 13:26:19 +0200 Subject: [Freeipa-devel] [PATCH 0112-7] Speeding up cli help In-Reply-To: <547fcaaa-c86c-f547-c049-2de82df78de8@redhat.com> References: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> <01ff40a4-b964-4f78-33dd-f1c92c490fdd@redhat.com> <29310e45-fc18-52fc-1686-651bb42480c9@redhat.com> <547fcaaa-c86c-f547-c049-2de82df78de8@redhat.com> Message-ID: On 4.8.2016 16:32, David Kupka wrote: > On 03/08/16 16:33, Jan Cholasta wrote: >> On 3.8.2016 16:23, David Kupka wrote: >>> On 21/07/16 10:12, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 20.7.2016 14:32, David Kupka wrote: >>>>> On 15/07/16 12:53, David Kupka wrote: >>>>>> Hello! >>>>>> >>>>>> After Honza introduced thin client that builds plugins and commands >>>>>> dynamically from schema client became much slower. This is only >>>>>> logical, >>>>>> instead of importing a module client now must fetch the schema from >>>>>> server, parse it and instantiate the commands using the data. >>>>>> >>>>>> First step to speed it up was addition of schema cache to client. >>>>>> That >>>>>> removed the RTT and download time of fetching schema every time. >>>>>> >>>>>> Now the most time consuming task became displaying help for lists of >>>>>> topics and command and displaying individual topics. This is simply >>>>>> because of the need to instantiate all the commands to find the >>>>>> relations between topics and commands. >>>>>> >>>>>> All the necessary bits for server commands and topics are already in >>>>>> the >>>>>> schema cache so we can skip this part and generate help from it, >>>>>> right? >>>>>> Not so fast! >>>>>> >>>>>> There are client plugins with commands and topics. So we can generate >>>>>> basic bits (list of all topics, list of all commands, list of >>>>>> commands >>>>>> for each topic) from schema and store it in cache. Then we need to go >>>>>> through all client plugins and get similar bits for client plugins. >>>>>> Then >>>>>> we can merge and print. >>>>>> >>>>>> Still the client response is not as fast as before and I this it even >>>>>> can't be. Also first time you display particular topic or list takes >>>>>> longer because it must be freshly generated and stored in cache for >>>>>> next >>>>>> use. And this is what the attached patches do. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6048 >>>>> >>>>> Reimplemented so there is no need to distinguish client plugins and >>>>> remote plugins. >>>>> The main idea of this approach is to avoid creating instances of the >>>>> commands just to get the information about topic, name and summary >>>>> needed for displaying help. Instead class properties are used to >>>>> access >>>>> the information directly in schema. >>>> >>>> Patch 0112: >>>> >>>> I think this would better be done in Schema.read_namespace_member, >>>> because Schema is where all the state is. >>>> >>>> (BTW does _SchemaNameSpace.__getitem__ raise KeyError for non-existent >>>> keys? It looks like it doesn't.) >>>> >>>> >>>> Patch 0113: >>>> >>>> How about setting _schema_cached to False in Schema.__init__() rather >>>> that getattr()-ing it in _ensure_cached()? >>>> >>>> >>>> Patch 0116: >>>> >>>> ClientCommand.doc should be a class property as well, otherwise >>>> .summary >>>> won't work on it correctly. >>>> >>>> _SchemaCommand.doc should not be a property, as it's not needed for >>>> .summary to work on it correctly. >>>> >>>> >>>> Otherwise works fine for me. >>>> >>>> Honza >>>> >>> >>> Updated patches attached. >> >> Thanks, ACK. >> >> Pushed to master: 229e2a1ed9ea9877cb5e879fadd99f9040f77c96 >> > > I've made and reviewer overlooked some errors. Attached patches fix them. Shame on me. Anyway, 1) When schema() raises SchemaUpToDate, the current code explodes: ipa: ERROR: KeyError: 'fingerprint' Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1348, in run api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 707, in finalize self.__do_if_not_done('load_plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 422, in __do_if_not_done getattr(self, name)() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 585, in load_plugins for package in self.packages: File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 919, in packages ipaclient.remote_plugins.get_package(self), File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", line 92, in get_package plugins = schema.get_package(api, server_info, client) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 558, in get_package fingerprint = str(schema['fingerprint']) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 483, in __getitem__ return self._dict[key] KeyError: 'fingerprint' 2) We read server info every time get_package() is called. It should be cache similarly to how the schema is cached in the api object. 3) Some of the commands are still fully initialized during "ipa help commands". Honza -- Jan Cholasta From jcholast at redhat.com Mon Aug 8 11:27:29 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 8 Aug 2016 13:27:29 +0200 Subject: [Freeipa-devel] [PATCH 685] parameters: move the `confirm` kwarg to Param Message-ID: Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-685-parameters-move-the-confirm-kwarg-to-Param.patch Type: text/x-patch Size: 2772 bytes Desc: not available URL: From mbasti at redhat.com Mon Aug 8 11:26:55 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 8 Aug 2016 13:26:55 +0200 Subject: [Freeipa-devel] [PATCH 685] parameters: move the `confirm` kwarg to Param In-Reply-To: References: Message-ID: On 08.08.2016 13:27, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > Please document this change in Param dosctring --- a/ipalib/parameters.py +++ b/ipalib/parameters.py @@ -418,6 +418,7 @@ class Param(ReadOnly): ('cli_metavar', str, None), ('no_convert', bool, False), ('deprecated', bool, False), + ('confirm', bool, True), Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Aug 8 11:27:22 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 14:27:22 +0300 Subject: [Freeipa-devel] [PATCH 0215-0216] Child domain fixes for AD trust Message-ID: <20160808112722.ldzcfmfpdzzmumex@redhat.com> Hi! Attached two patches attempt to fix some of the issues we see with child domains. SSSD only 'sees' users from child domains if there is an ID range for each of them. However, after refactoring of trust code when external trust was introduced, part of the range creation had wrong assumption that if a trusted domain exists, its range also exists. This is now fixed to try to create range even if the domain exists. In fact, because the older code was not going to the range creation for trusted domains which already existed, adding ranges was done incorrectly: ID ranges use full domain name and don't need - hierarchy, but the code was passing both parent and the child names. As result, an attempt to create an ID range for parent was done instead of the child. Parent ID range already existed so we never got to create child ID ranges at all in that case. Finally, there is a fix in SSSD to properly generate CA paths so that libkrb5 can calculate correct trust path via forest root (parent) domain. While looking at that, I also decided to simplify logic in ipa-kdb driver because for cross-forest trust we never can transit to the child domain directly, we always have to use the forest root domain. However, old code could actually set a immediate domain's parent instead of the forest root for deep level trust relationship within the forest we trust. As we still cannot get to second level or beyond directly or via their actual parent domain, we always have to go through the forest root domain. The simplified code enforces this logic. -- / Alexander Bokovoy -------------- next part -------------- From 37e4ab4786aec94bfb057fa3146d4e18e30df391 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Sat, 6 Aug 2016 11:12:13 +0300 Subject: [PATCH 4/5] trust: make sure ID range is created for the child domain even if it exists ID ranges for child domains of a forest trust were created incorrectly in FreeIPA 4.4.0 due to refactoring of -- if the domain was already existing, we never attempted to create the ID range for it. At the same time, when domain was missing, we attempted to add ID range and passed both forest root and the child domain names to add_range(). However, add_range() only looks at the first positional argument which was the forest root name. That ID range always exists (it is created before child domains are processed). Modify the code to make sure child domain name is passed as the first positional argument. In addition, the oddjob helper should explicitly set context='server' so that idrange code will be able to see and use ipaserver/dcerpc.py helpers. Resolves: https://fedorahosted.org/freeipa/ticket/5738 --- install/oddjob/com.redhat.idm.trust-fetch-domains | 2 +- ipaserver/plugins/trust.py | 10 +++++++--- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/install/oddjob/com.redhat.idm.trust-fetch-domains b/install/oddjob/com.redhat.idm.trust-fetch-domains index 7c948fd..bffa021 100755 --- a/install/oddjob/com.redhat.idm.trust-fetch-domains +++ b/install/oddjob/com.redhat.idm.trust-fetch-domains @@ -76,7 +76,7 @@ env._bootstrap(debug=options.debug, log=None) env._finalize_core(**dict(DEFAULT_CONFIG)) # Initialize the API with the proper debug level -api.bootstrap(in_server=True, debug=env.debug, log=None) +api.bootstrap(in_server=True, debug=env.debug, log=None, context='server') api.finalize() # Only import trust plugin after api is initialized or internal imports diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py index f2e0b1e..f90d9c1 100644 --- a/ipaserver/plugins/trust.py +++ b/ipaserver/plugins/trust.py @@ -1673,15 +1673,19 @@ def add_new_domains_from_trust(myapi, trustinstance, trust_entry, domains, **opt if 'raw' in options: dom['raw'] = options['raw'] - res = myapi.Command.trustdomain_add(trust_name, name, **dom) - result.append(res['result']) + try: + res = myapi.Command.trustdomain_add(trust_name, name, **dom) + result.append(res['result']) + except errors.DuplicateEntry: + # Ignore updating duplicate entries + pass if idrange_type != u'ipa-ad-trust-posix': range_name = name.upper() + '_id_range' dom['range_type'] = u'ipa-ad-trust' add_range(myapi, trustinstance, range_name, dom['ipanttrusteddomainsid'], - trust_name, name, **dom) + name, **dom) except errors.DuplicateEntry: # Ignore updating duplicate entries pass -- 2.7.4 -------------- next part -------------- From 767458d1532feb7029ff9a52e67e931fd87869ec Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Sun, 7 Aug 2016 21:42:14 +0300 Subject: [PATCH 5/5] ipa-kdb: simplify trusted domain parent search In terms of cross-forest trust parent domain is the root domain of the forest because we only have trust established with the forest root. In FreeIPA LDAP store all sub-domains stored in cn=, cn=ad,cn=trusts,... subtree. Thus, a first RDN after cn=ad is the forest root domain. This allows us to simplify logic of finding the parent domain. For complex hierachical forests with more than two levels of sub-domains, this will still be true because of the forest trust: as forest trust is established to the forest root domain, any communication to any sub-domain must traverse forest root domain's domain controller. Note that SSSD also generated incorrectly CA paths information for forests with non-hierarchical tree-roots. In such cases IPA KDC got confused and mistakenly assumed direct trust to the non-hierarchical tree-root instead of going through the forest root domain. See https://fedorahosted.org/sssd/ticket/3103 for details. Resolves: https://fedorahosted.org/freeipa/ticket/5738 --- daemons/ipa-kdb/ipa_kdb_mspac.c | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 80e7055..76e9e99 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -2420,6 +2420,7 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) char *base = NULL; char *dnstr = NULL; char *dnl = NULL; + LDAPDN dn = NULL; char **sid_blacklist_incoming = NULL; char **sid_blacklist_outgoing = NULL; int ret, n, i; @@ -2547,26 +2548,26 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) goto done; } - /* Note that after ldap_str2rdn() call dnl will point to end of one RDN - * which would be '\0' for trust root domain and ',' for subdomain */ dnl--; dnl[0] = '\0'; - ret = ldap_str2rdn(dnstr, &rdn, &dnl, LDAP_DN_FORMAT_LDAPV3); + /* Create a DN, which is now everything before the base, + * to get list of rdn values -- the last one would be a root domain. + * Since with cross-forest trust we have to route everything via root + * domain, that is enough for us to assign parentship. */ + ret = ldap_str2dn(dnstr, &dn, LDAP_DN_FORMAT_LDAPV3); if (ret) { goto done; } - ldap_rdnfree(rdn); - - if (dnl[0] != '\0') { - dnl++; - ret = ldap_str2rdn(dnl, &rdn, &dnl, LDAP_DN_FORMAT_LDAPV3); - if (ret) { - goto done; - } - t[n].parent_name = strndup(rdn[0]->la_value.bv_val, rdn[0]->la_value.bv_len); - ldap_rdnfree(rdn); + rdn = NULL; + for (i = 0; dn[i] != NULL; i++) { + rdn = dn[i]; } + /* We should have a single AVA in the domain RDN */ + t[n].parent_name = strndup(rdn[0]->la_value.bv_val, rdn[0]->la_value.bv_len); + + ldap_dnfree(dn); + free(dnstr); dnstr = NULL; } -- 2.7.4 From tbordaz at redhat.com Mon Aug 8 11:30:18 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 8 Aug 2016 13:30:18 +0200 Subject: [Freeipa-devel] [PATCH] ipa_pwd_extop: Fix warning declaration shadows previous In-Reply-To: <20160805121651.GH6891@10.4.128.1> References: <20160805121651.GH6891@10.4.128.1> Message-ID: <57A86D4A.8050803@redhat.com> On 08/05/2016 02:16 PM, Lukas Slebodnik wrote: > ehlo, > > attached patches fixes few compiler warnings in ipa-extop. > Sorry for not following naming convention for patches. > But I do not remeber my numer and you will use github/pagure > anyway. > > LS > > Hi Lukas, 0001-ipa_pwd_extop-Fix-warning-decalration-shadows-previo.patch looks ok but there is a leak in the remaining code. In fact bind_sdn and target_sdn need to be freed (slapi_sdn_free(&xxx)) before the end of the 'if (dn)' statement. Do you want to fix it in your patch of should we use an other patch ? 0002-ipa-pwd-extop-Fix-warning-assignment-discards-const-.patch is ok. Ack thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Mon Aug 8 11:31:09 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 8 Aug 2016 13:31:09 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate In-Reply-To: References: Message-ID: <20160808113109.GT1586@redhat.com> On Mon, Aug 08, 2016 at 12:52:33PM +0200, Martin Kosek wrote: > > I discussed this with Jan Pazdziora on IRC, outside of this mail thread, so let > me repeat my suggestion here. I still think it is premature to add plugins like > that to FreeIPA core git. We are not agreed yet how we will distribute FreeIPA > plugins, so I would not rush adding this plugin to FreeIPA core, especially > since it is very experimental and not even secure yet. FreeIPA plugin > distribution should be more thought through and discussed. > > As I proposed, this plugin can now live outside of FreeIPA core git, in it's > own life cycle (maybe in freeipa-plugins github git repo we create?) so that it > can be updated without updating whole FreeIPA core. In this effort, I would > suggest to only consider updates of > > * ipaserver/plugins/xmlserver.py > * ipaserver/rpcserver.py > > as these would have to patched by admin deploying this feature and would be > overwritten by RPM updates. The plugin itself or server.conf can be deployed > and installed separatenly, even via other RPM. We want the feature (albeit experimental) to be available to upstream users and downstream customers, with as few steps to take and as few hoops to jump through as possible. Any bits we can get to users' and customers' hands via standard means are bits that they don't need to get from elsewhere, via nonstandard means, with us inventing and supporting these nonstandards processes. Assuming the mere existence of the functionality (which will be disabled by default) does not decrease security of the default installations and configuration, I don't see why carrying it poses a problem. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From pvomacka at redhat.com Mon Aug 8 11:32:02 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Mon, 8 Aug 2016 13:32:02 +0200 Subject: [Freeipa-devel] [PATCH] 0100: Fix question marks in adders in topology graph In-Reply-To: References: Message-ID: On 08/05/2016 02:15 PM, Pavel Vomacka wrote: > Hello, > > Please review attached patch. > > https://fedorahosted.org/freeipa/ticket/6175 > > > Changed commit message. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0100-2-Fix-unicode-characters-in-ca-and-domain-adders.patch Type: text/x-patch Size: 1606 bytes Desc: not available URL: From jcholast at redhat.com Mon Aug 8 11:37:04 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 8 Aug 2016 13:37:04 +0200 Subject: [Freeipa-devel] [PATCH 0154] client: RPM require initscripts to get *-domainname.service In-Reply-To: <6b6bb9c3-9ac9-27c7-9e4c-3e637cab6744@redhat.com> References: <6b6bb9c3-9ac9-27c7-9e4c-3e637cab6744@redhat.com> Message-ID: Hi, On 8.8.2016 13:22, Petr Spacek wrote: > Hello, > > client: RPM require initscripts to get *-domainname.service > > https://fedorahosted.org/freeipa/ticket/4831 IIRC there was a task associated with the ticket to investigate if there is a better way of setting the domain name on boot. So... is there? AFAIK we set the domain name using authconfig, shouldn't authconfig be in charge of enabling any required services? Honza -- Jan Cholasta From jcholast at redhat.com Mon Aug 8 11:40:49 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 8 Aug 2016 13:40:49 +0200 Subject: [Freeipa-devel] [PATCH 685] parameters: move the `confirm` kwarg to Param In-Reply-To: References: Message-ID: <71af5d7f-a48d-39e0-0b27-90835126fdb8@redhat.com> On 8.8.2016 13:26, Martin Basti wrote: > > > On 08.08.2016 13:27, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > Please document this change in Param dosctring > > --- a/ipalib/parameters.py > +++ b/ipalib/parameters.py > @@ -418,6 +418,7 @@ class Param(ReadOnly): > ('cli_metavar', str, None), > ('no_convert', bool, False), > ('deprecated', bool, False), > + ('confirm', bool, True), > > > Martin^2 > > -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-685.1-parameters-move-the-confirm-kwarg-to-Param.patch Type: text/x-patch Size: 3119 bytes Desc: not available URL: From mkosek at redhat.com Mon Aug 8 11:43:42 2016 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 8 Aug 2016 13:43:42 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate In-Reply-To: <20160808113109.GT1586@redhat.com> References: <20160808113109.GT1586@redhat.com> Message-ID: <6423abf9-773d-9a4b-f09d-298e59b77e8a@redhat.com> On 08/08/2016 01:31 PM, Jan Pazdziora wrote: > On Mon, Aug 08, 2016 at 12:52:33PM +0200, Martin Kosek wrote: >> >> I discussed this with Jan Pazdziora on IRC, outside of this mail thread, so let >> me repeat my suggestion here. I still think it is premature to add plugins like >> that to FreeIPA core git. We are not agreed yet how we will distribute FreeIPA >> plugins, so I would not rush adding this plugin to FreeIPA core, especially >> since it is very experimental and not even secure yet. FreeIPA plugin >> distribution should be more thought through and discussed. >> >> As I proposed, this plugin can now live outside of FreeIPA core git, in it's >> own life cycle (maybe in freeipa-plugins github git repo we create?) so that it >> can be updated without updating whole FreeIPA core. In this effort, I would >> suggest to only consider updates of >> >> * ipaserver/plugins/xmlserver.py >> * ipaserver/rpcserver.py >> >> as these would have to patched by admin deploying this feature and would be >> overwritten by RPM updates. The plugin itself or server.conf can be deployed >> and installed separatenly, even via other RPM. > > We want the feature (albeit experimental) to be available to upstream > users and downstream customers, with as few steps to take and as few > hoops to jump through as possible. Any bits we can get to users' and > customers' hands via standard means are bits that they don't need to > get from elsewhere, via nonstandard means, with us inventing and > supporting these nonstandards processes. > > Assuming the mere existence of the functionality (which will be > disabled by default) does not decrease security of the default > installations and configuration, I don't see why carrying it poses > a problem. I see your reasoning, I just think it is not strong enough to rush this new method of delivering plugins in before discussing it more broadly. Also, as I mentioned, we may want different life cycle for FreeIPA plugins that we want for FreeIPA core bits. Thus the different repository suggestion. This whole feature is (still) non-standard and experimental, so I do not personally see that big problem in non-standard delivery mechanism. Martin From jcholast at redhat.com Mon Aug 8 11:52:31 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 8 Aug 2016 13:52:31 +0200 Subject: [Freeipa-devel] [PATCH] 0001: Silence sshd messages during install In-Reply-To: <19dd378c-cc99-90f5-411c-7f472b87775f@redhat.com> References: <3fe0b9ae-9b22-3a9a-3d4a-067c51a22452@redhat.com> <19dd378c-cc99-90f5-411c-7f472b87775f@redhat.com> Message-ID: On 19.7.2016 08:40, Jan Cholasta wrote: > Hi, > > On 9.7.2016 14:46, Ben Lipton wrote: >> On 07/07/2016 11:19 AM, Ben Lipton wrote: >>> >>> Thanks for the review! Comments below. >>> >>> >>> On 07/01/2016 07:42 AM, Martin Basti wrote: >>>> >>>> >>>> >>>> On 29.06.2016 20:46, Ben Lipton wrote: >>>>> The attached patch silences some annoying messages I've been getting >>>>> when upgrading the freeipa-client package on F24: >>>>> """ >>>>> WARNING: 'UseLogin yes' is not supported in Fedora and may cause >>>>> several problems. >>> This will be fixed by openssh-7.2p2-9.fc24 >>> (https://bugzilla.redhat.com/show_bug.cgi?id=1350347) so we probably >>> shouldn't worry about it. >>>>> Could not load host key: /etc/ssh/ssh_host_dsa_key >>> This is because by default sshd looks for all of >>> /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, >>> /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key, but >>> Fedora doesn't generate a DSA key by default. >>>>> """ >>>>> >>>>> Since the script causing the message only looks at the return code >>>>> from sshd to determine the right options to use, I thought it might >>>>> be ok to discard the output. What do you think? >>>>> >>>>> Ben >>>>> >>>>> >>>> >>>> Hello, I don't like to hiding errors/warnings. Can you determine and >>>> solve the root cause? >>> >>> I definitely agree with this in principle, but in this case the >>> purpose of this code is to try different, potentially wrong, >>> parameters to sshd until it finds a combination that it accepts. It >>> seems like in some environments this would produce error messages that >>> aren't actionable and don't indicate any problem for package function, >>> which is why I didn't think these messages were necessarily worth >>> preserving. >>> >>> On the other hand, if the code makes the wrong decision about sshd >>> version we might be interested in error logs that show why. Can we log >>> this to a file instead of the console, maybe? >>> >>> If you'd prefer just addressing the root cause, a patch that prevents >>> the missing host key error is attached, but it won't stop the error >>> messages showing up when openssh is an older version. >>> >>> Thanks, >>> Ben >>> >>> >> Whoops, realized that my patch created a tempfile and didn't delete it. >> Updated. > > I think the first version of the patch was OK. sshd is called only to > check which set of authorized keys options to use, we don't really care > about anything else, so we can safely ignore whatever it puts to stderr. Bump. ACK on the first version of the patch (freeipa-blipton-0001-Silence-sshd-messages-during-install.patch). Anyone against pushing it? > > Honza > -- Jan Cholasta From pspacek at redhat.com Mon Aug 8 11:48:41 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 8 Aug 2016 13:48:41 +0200 Subject: [Freeipa-devel] [PATCH 0154] client: RPM require initscripts to get *-domainname.service In-Reply-To: References: <6b6bb9c3-9ac9-27c7-9e4c-3e637cab6744@redhat.com> Message-ID: <2493f706-b8c7-5848-a3a3-bc064e90f44a@redhat.com> On 8.8.2016 13:37, Jan Cholasta wrote: > Hi, > > On 8.8.2016 13:22, Petr Spacek wrote: >> Hello, >> >> client: RPM require initscripts to get *-domainname.service >> >> https://fedorahosted.org/freeipa/ticket/4831 > > IIRC there was a task associated with the ticket to investigate if there is a > better way of setting the domain name on boot. So... is there? > > AFAIK we set the domain name using authconfig, shouldn't authconfig be in > charge of enabling any required services? As far as I can tell, this is the way to set NIS domain in RHEL/Fedora. authconfig cannot set NIS domain only, it does unwanted additional magic like enabling rpcbind and ypbind services etc. Alternative is to drop sysctl file to /etc but I do not like it because it would not be the Red Hat standard way of doing NIS domain config. Opinions? -- Petr^2 Spacek From lslebodn at redhat.com Mon Aug 8 11:56:47 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 8 Aug 2016 13:56:47 +0200 Subject: [Freeipa-devel] [PATCH] ipa_pwd_extop: Fix warning declaration shadows previous In-Reply-To: <57A86D4A.8050803@redhat.com> References: <20160805121651.GH6891@10.4.128.1> <57A86D4A.8050803@redhat.com> Message-ID: <20160808115647.GE7069@10.4.128.1> On (08/08/16 13:30), thierry bordaz wrote: > > >On 08/05/2016 02:16 PM, Lukas Slebodnik wrote: >> ehlo, >> >> attached patches fixes few compiler warnings in ipa-extop. >> Sorry for not following naming convention for patches. >> But I do not remeber my numer and you will use github/pagure >> anyway. >> >> LS >> >> >Hi Lukas, > >0001-ipa_pwd_extop-Fix-warning-decalration-shadows-previo.patch looks ok but >there is a leak in the remaining code. >In fact bind_sdn and target_sdn need to be freed (slapi_sdn_free(&xxx)) >before the end of the 'if (dn)' statement. >Do you want to fix it in your patch of should we use an other patch ? > > >0002-ipa-pwd-extop-Fix-warning-assignment-discards-const-.patch is ok. Ack > If I it is not introduced by this patch then it will be better to prepare another patch. "git blame" would be confusing. Thank you for review. LS From abokovoy at redhat.com Mon Aug 8 11:58:31 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 14:58:31 +0300 Subject: [Freeipa-devel] [PATCH] 0001: Silence sshd messages during install In-Reply-To: References: <3fe0b9ae-9b22-3a9a-3d4a-067c51a22452@redhat.com> <19dd378c-cc99-90f5-411c-7f472b87775f@redhat.com> Message-ID: <20160808115831.s7eylgmmdrg5sift@redhat.com> On Mon, 08 Aug 2016, Jan Cholasta wrote: >On 19.7.2016 08:40, Jan Cholasta wrote: >>Hi, >> >>On 9.7.2016 14:46, Ben Lipton wrote: >>>On 07/07/2016 11:19 AM, Ben Lipton wrote: >>>> >>>>Thanks for the review! Comments below. >>>> >>>> >>>>On 07/01/2016 07:42 AM, Martin Basti wrote: >>>>> >>>>> >>>>> >>>>>On 29.06.2016 20:46, Ben Lipton wrote: >>>>>>The attached patch silences some annoying messages I've been getting >>>>>>when upgrading the freeipa-client package on F24: >>>>>>""" >>>>>>WARNING: 'UseLogin yes' is not supported in Fedora and may cause >>>>>>several problems. >>>>This will be fixed by openssh-7.2p2-9.fc24 >>>>(https://bugzilla.redhat.com/show_bug.cgi?id=1350347) so we probably >>>>shouldn't worry about it. >>>>>>Could not load host key: /etc/ssh/ssh_host_dsa_key >>>>This is because by default sshd looks for all of >>>>/etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, >>>>/etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key, but >>>>Fedora doesn't generate a DSA key by default. >>>>>>""" >>>>>> >>>>>>Since the script causing the message only looks at the return code >>>>>>from sshd to determine the right options to use, I thought it might >>>>>>be ok to discard the output. What do you think? >>>>>> >>>>>>Ben >>>>>> >>>>>> >>>>> >>>>>Hello, I don't like to hiding errors/warnings. Can you determine and >>>>>solve the root cause? >>>> >>>>I definitely agree with this in principle, but in this case the >>>>purpose of this code is to try different, potentially wrong, >>>>parameters to sshd until it finds a combination that it accepts. It >>>>seems like in some environments this would produce error messages that >>>>aren't actionable and don't indicate any problem for package function, >>>>which is why I didn't think these messages were necessarily worth >>>>preserving. >>>> >>>>On the other hand, if the code makes the wrong decision about sshd >>>>version we might be interested in error logs that show why. Can we log >>>>this to a file instead of the console, maybe? >>>> >>>>If you'd prefer just addressing the root cause, a patch that prevents >>>>the missing host key error is attached, but it won't stop the error >>>>messages showing up when openssh is an older version. >>>> >>>>Thanks, >>>>Ben >>>> >>>> >>>Whoops, realized that my patch created a tempfile and didn't delete it. >>>Updated. >> >>I think the first version of the patch was OK. sshd is called only to >>check which set of authorized keys options to use, we don't really care >>about anything else, so we can safely ignore whatever it puts to stderr. > >Bump. > >ACK on the first version of the patch >(freeipa-blipton-0001-Silence-sshd-messages-during-install.patch). > >Anyone against pushing it? Given that newer OpenSSH version will silence it anyway, I'm OK with the interim fix. -- / Alexander Bokovoy From tbordaz at redhat.com Mon Aug 8 11:58:36 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 8 Aug 2016 13:58:36 +0200 Subject: [Freeipa-devel] [PATCH] ipa_pwd_extop: Fix warning declaration shadows previous In-Reply-To: <20160808115647.GE7069@10.4.128.1> References: <20160805121651.GH6891@10.4.128.1> <57A86D4A.8050803@redhat.com> <20160808115647.GE7069@10.4.128.1> Message-ID: <57A873EC.7050302@redhat.com> On 08/08/2016 01:56 PM, Lukas Slebodnik wrote: > On (08/08/16 13:30), thierry bordaz wrote: >> >> On 08/05/2016 02:16 PM, Lukas Slebodnik wrote: >>> ehlo, >>> >>> attached patches fixes few compiler warnings in ipa-extop. >>> Sorry for not following naming convention for patches. >>> But I do not remeber my numer and you will use github/pagure >>> anyway. >>> >>> LS >>> >>> >> Hi Lukas, >> >> 0001-ipa_pwd_extop-Fix-warning-decalration-shadows-previo.patch looks ok but >> there is a leak in the remaining code. >> In fact bind_sdn and target_sdn need to be freed (slapi_sdn_free(&xxx)) >> before the end of the 'if (dn)' statement. >> Do you want to fix it in your patch of should we use an other patch ? >> >> >> 0002-ipa-pwd-extop-Fix-warning-assignment-discards-const-.patch is ok. Ack >> > If I it is not introduced by this patch then it will be better > to prepare another patch. "git blame" would be confusing. > > Thank you for review. > > LS Hi Lukas, Ok I will prepare a patch for the leaks. Both patches are ok. ACK thanks thierry From Peter.Marx at knorr-bremse.com Mon Aug 8 12:23:13 2016 From: Peter.Marx at knorr-bremse.com (Marx, Peter) Date: Mon, 8 Aug 2016 12:23:13 +0000 Subject: [Freeipa-devel] certmonger proxy configuration not possible ? In-Reply-To: <20160808094807.dy2ly5z7uqnnsbxv@redhat.com> References: <2C720BBFE8885346B9A4377911BABE7886889266@MUCS72046.corp.knorr-bremse.com> <57A1F6EA.9080901@redhat.com> <2C720BBFE8885346B9A4377911BABE788688ADD9@MUCS72046.corp.knorr-bremse.com> <20160804160147.2mq54tfooquehlvh@redhat.com> <2C720BBFE8885346B9A4377911BABE788688CA5F@MUCS72046.corp.knorr-bremse.com> <20160808094807.dy2ly5z7uqnnsbxv@redhat.com> Message-ID: <2C720BBFE8885346B9A4377911BABE788688CC72@MUCS72046.corp.knorr-bremse.com> what I feared... ok. I will open an enhancement ticket. Hopefully somebody can provide a preliminary patch I can apply. -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Monday, August 08, 2016 11:48 AM To: Marx, Peter Cc: Rob Crittenden; 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certmonger proxy configuration not possible ? On Mon, 08 Aug 2016, Marx, Peter wrote: >I am trying this but it has no effect - as if the environment is not passed to the called helper scep-submit. > >In /usr/lib/systemd/certmonger.service there is already a link defined to add stuff: >[Service] >.. >EnvironmentFile=/etc/sysconfig/certmonger > >In /etc/sysconfig/certmonger I added my proxy like this: > >[Service] >Environment="http_proxy=http://proxyuser:proxypassword at proxyserver:proxyport" > >After systemctl daemon-reload and systemctl restart certmonger my >requests still do not get to the proxy. > >Commenting out the EnvironmetFile line and adding the Environment line >directly in certmonger.service had the same result. > >Can somebody confirm that the proxy setting is visible to the called >scep-submit ? I've checked certmonger source code and while libcurl can be configured to use proxy and proxy authentication, certmonger does not configure it to do so. As result, environmental variables have no influence on the use of libcurl by certmonger. It is worth to open a ticket for certmonger to add proxy support. -- / Alexander Bokovoy automechanika - 13.09.-17.09.2016 - Messe Frankfurt - Hall 3.0 - Stand G98 + E91 InnoTrans - 20.09.-23.09.2016 - Messe Berlin - Hall 1.2b - Stand 104 + 210 IAA - 22.09.-29.09.2016 - Messe Hannover - Hall 17 - Stand A30 + D131 Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. From mbasti at redhat.com Mon Aug 8 12:25:01 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 8 Aug 2016 14:25:01 +0200 Subject: [Freeipa-devel] [PATCH] 0001: Silence sshd messages during install In-Reply-To: <20160808115831.s7eylgmmdrg5sift@redhat.com> References: <3fe0b9ae-9b22-3a9a-3d4a-067c51a22452@redhat.com> <19dd378c-cc99-90f5-411c-7f472b87775f@redhat.com> <20160808115831.s7eylgmmdrg5sift@redhat.com> Message-ID: <40c23042-0d7b-c9a8-6c3a-124363897fe3@redhat.com> On 08.08.2016 13:58, Alexander Bokovoy wrote: > On Mon, 08 Aug 2016, Jan Cholasta wrote: >> On 19.7.2016 08:40, Jan Cholasta wrote: >>> Hi, >>> >>> On 9.7.2016 14:46, Ben Lipton wrote: >>>> On 07/07/2016 11:19 AM, Ben Lipton wrote: >>>>> >>>>> Thanks for the review! Comments below. >>>>> >>>>> >>>>> On 07/01/2016 07:42 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 29.06.2016 20:46, Ben Lipton wrote: >>>>>>> The attached patch silences some annoying messages I've been >>>>>>> getting >>>>>>> when upgrading the freeipa-client package on F24: >>>>>>> """ >>>>>>> WARNING: 'UseLogin yes' is not supported in Fedora and may cause >>>>>>> several problems. >>>>> This will be fixed by openssh-7.2p2-9.fc24 >>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=1350347) so we probably >>>>> shouldn't worry about it. >>>>>>> Could not load host key: /etc/ssh/ssh_host_dsa_key >>>>> This is because by default sshd looks for all of >>>>> /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, >>>>> /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key, but >>>>> Fedora doesn't generate a DSA key by default. >>>>>>> """ >>>>>>> >>>>>>> Since the script causing the message only looks at the return code >>>>>>> from sshd to determine the right options to use, I thought it might >>>>>>> be ok to discard the output. What do you think? >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> >>>>>> >>>>>> Hello, I don't like to hiding errors/warnings. Can you determine and >>>>>> solve the root cause? >>>>> >>>>> I definitely agree with this in principle, but in this case the >>>>> purpose of this code is to try different, potentially wrong, >>>>> parameters to sshd until it finds a combination that it accepts. It >>>>> seems like in some environments this would produce error messages >>>>> that >>>>> aren't actionable and don't indicate any problem for package >>>>> function, >>>>> which is why I didn't think these messages were necessarily worth >>>>> preserving. >>>>> >>>>> On the other hand, if the code makes the wrong decision about sshd >>>>> version we might be interested in error logs that show why. Can we >>>>> log >>>>> this to a file instead of the console, maybe? >>>>> >>>>> If you'd prefer just addressing the root cause, a patch that prevents >>>>> the missing host key error is attached, but it won't stop the error >>>>> messages showing up when openssh is an older version. >>>>> >>>>> Thanks, >>>>> Ben >>>>> >>>>> >>>> Whoops, realized that my patch created a tempfile and didn't delete >>>> it. >>>> Updated. >>> >>> I think the first version of the patch was OK. sshd is called only to >>> check which set of authorized keys options to use, we don't really care >>> about anything else, so we can safely ignore whatever it puts to >>> stderr. >> >> Bump. >> >> ACK on the first version of the patch >> (freeipa-blipton-0001-Silence-sshd-messages-during-install.patch). >> >> Anyone against pushing it? > Given that newer OpenSSH version will silence it anyway, I'm OK with the > interim fix. Pushed to master: c15ba1f9e8c7d236586d46271fce7c3950b509da From mbasti at redhat.com Mon Aug 8 12:35:46 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 8 Aug 2016 14:35:46 +0200 Subject: [Freeipa-devel] [PATCH] ipa_pwd_extop: Fix warning declaration shadows previous In-Reply-To: <57A873EC.7050302@redhat.com> References: <20160805121651.GH6891@10.4.128.1> <57A86D4A.8050803@redhat.com> <20160808115647.GE7069@10.4.128.1> <57A873EC.7050302@redhat.com> Message-ID: <3f1e6072-b451-7d14-304e-ca5a98c99bc8@redhat.com> On 08.08.2016 13:58, thierry bordaz wrote: > > > On 08/08/2016 01:56 PM, Lukas Slebodnik wrote: >> On (08/08/16 13:30), thierry bordaz wrote: >>> >>> On 08/05/2016 02:16 PM, Lukas Slebodnik wrote: >>>> ehlo, >>>> >>>> attached patches fixes few compiler warnings in ipa-extop. >>>> Sorry for not following naming convention for patches. >>>> But I do not remeber my numer and you will use github/pagure >>>> anyway. >>>> >>>> LS >>>> >>>> >>> Hi Lukas, >>> >>> 0001-ipa_pwd_extop-Fix-warning-decalration-shadows-previo.patch >>> looks ok but >>> there is a leak in the remaining code. >>> In fact bind_sdn and target_sdn need to be freed (slapi_sdn_free(&xxx)) >>> before the end of the 'if (dn)' statement. >>> Do you want to fix it in your patch of should we use an other patch ? >>> >>> >>> 0002-ipa-pwd-extop-Fix-warning-assignment-discards-const-.patch is >>> ok. Ack >>> >> If I it is not introduced by this patch then it will be better >> to prepare another patch. "git blame" would be confusing. >> >> Thank you for review. >> >> LS > Hi Lukas, > > Ok I will prepare a patch for the leaks. > > Both patches are ok. ACK > > thanks > thierry > Pushed to master: 7e1898bd014234c176b0c5d4d00463c70fba27b0 Pushed to master: 50c53395de7b5b4c62f3bc9004d2c7a94792339f From tbordaz at redhat.com Mon Aug 8 13:58:41 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 8 Aug 2016 15:58:41 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <20160808085623.daozgyxrlltzviuu@redhat.com> References: <20160808073457.vrcrunrodu5px433@redhat.com> <20160808083518.x2ose47ttuotcdsy@redhat.com> <20160808085100.GD7069@10.4.128.1> <20160808085623.daozgyxrlltzviuu@redhat.com> Message-ID: <57A89011.9050103@redhat.com> On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: > On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >> On (08/08/16 11:35), Alexander Bokovoy wrote: >>> On Mon, 08 Aug 2016, Martin Basti wrote: >>>> >>>> >>>> On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>> > When SSSD resolves AD users on behalf of slapi-nis, it can accept >>>> any >>>> > user identifier, including user principal name (UPN) which may be >>>> > different than the canonical user name which SSSD returns. >>>> > >>>> > As result, the entry created by slapi-nis will be using canonical >>>> user >>>> > name but the filter for search will refer to the original (aliased) >>>> > name. The search will not match the newly created entry. >>>> > >>>> > The issue is fixed in slapi-nis-0.56.1 by returning two values for >>>> > 'uid' attribute: the canonical one and the aliased one. This way the >>>> > search will match. >>>> > >>>> > Standard LDAP schema allows multiple values for 'uid' attribute. We >>>> > actually use the same trick for 'cn' attribute in the groups map >>>> > already. >>>> > >>>> > https://fedorahosted.org/freeipa/ticket/6138 >>>> > >>>> > >>>> > >>>> > >>>> Hello, >>>> >>>> should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>> No, this is not required. In Fedora we'll submit a combined update -- >>> I've built slapi-nis-0.56.1-1 packages for f24, f25, and rawhide >>> already >>> but did not submit a Bodhi request. >>> >> How is combined updated related to requires to slapi-nis-0.56.1? >> It will not prevent tu update freeipa without new slapi-nis. >> >> e.g. >> dnf update freeipa-server. > An update file in FreeIPA that is proposed by this patch does not affect > operation of the older slapi-nis deployment once update is applied. > Hi, Is '%first' returning the first value of the attribute 'uid' ? If there are several values (canonical, alias,... ), does the order matters ? thanks thierry From cheimes at redhat.com Mon Aug 8 14:09:38 2016 From: cheimes at redhat.com (Christian Heimes) Date: Mon, 8 Aug 2016 16:09:38 +0200 Subject: [Freeipa-devel] [PATCH 0034] Secure permissions of Custodia server.keys Message-ID: <164526c4-5b07-669f-3887-0f5772d348a7@redhat.com> I have split up patch 0032 into two smaller patches. This patch only addresses the server.keys file. Custodia's server.keys file contain the private RSA keys for encrypting and signing Custodia messages. The file was created with permission 644 and is only secured by permission 700 of the directory /etc/ipa/custodia. The installer and upgrader ensure that the file has 600. https://bugzilla.redhat.com/show_bug.cgi?id=1353936 https://fedorahosted.org/freeipa/ticket/6056 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0034-Secure-permissions-of-Custodia-server.keys.patch Type: text/x-patch Size: 2245 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From cheimes at redhat.com Mon Aug 8 14:10:38 2016 From: cheimes at redhat.com (Christian Heimes) Date: Mon, 8 Aug 2016 16:10:38 +0200 Subject: [Freeipa-devel] [PATCH 0035] Remove Custodia server keys from LDAP Message-ID: The server-del plugin now removes the Custodia keys for encryption and key signing from LDAP. https://fedorahosted.org/freeipa/ticket/6015 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0035-Remove-Custodia-server-keys-from-LDAP.patch Type: text/x-patch Size: 3212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From abokovoy at redhat.com Mon Aug 8 14:20:52 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 17:20:52 +0300 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <57A89011.9050103@redhat.com> References: <20160808073457.vrcrunrodu5px433@redhat.com> <20160808083518.x2ose47ttuotcdsy@redhat.com> <20160808085100.GD7069@10.4.128.1> <20160808085623.daozgyxrlltzviuu@redhat.com> <57A89011.9050103@redhat.com> Message-ID: <20160808142052.23rcbyd7llbljbfi@redhat.com> On Mon, 08 Aug 2016, thierry bordaz wrote: > > >On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>On Mon, 08 Aug 2016, Martin Basti wrote: >>>>> >>>>> >>>>>On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>> When SSSD resolves AD users on behalf of slapi-nis, it can >>>>>accept any >>>>>> user identifier, including user principal name (UPN) which may be >>>>>> different than the canonical user name which SSSD returns. >>>>>> >>>>>> As result, the entry created by slapi-nis will be using >>>>>canonical user >>>>>> name but the filter for search will refer to the original (aliased) >>>>>> name. The search will not match the newly created entry. >>>>>> >>>>>> The issue is fixed in slapi-nis-0.56.1 by returning two values for >>>>>> 'uid' attribute: the canonical one and the aliased one. This way the >>>>>> search will match. >>>>>> >>>>>> Standard LDAP schema allows multiple values for 'uid' attribute. We >>>>>> actually use the same trick for 'cn' attribute in the groups map >>>>>> already. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6138 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Hello, >>>>> >>>>>should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>>>No, this is not required. In Fedora we'll submit a combined update -- >>>>I've built slapi-nis-0.56.1-1 packages for f24, f25, and rawhide >>>>already >>>>but did not submit a Bodhi request. >>>> >>>How is combined updated related to requires to slapi-nis-0.56.1? >>>It will not prevent tu update freeipa without new slapi-nis. >>> >>>e.g. >>> dnf update freeipa-server. >>An update file in FreeIPA that is proposed by this patch does not affect >>operation of the older slapi-nis deployment once update is applied. >> > >Hi, > >Is '%first' returning the first value of the attribute 'uid' ? >If there are several values (canonical, alias,... ), does the order >matters ? We insert the canonical one first and it seems that 389-ds does not change the order, at least in my tests. You can see the output in the bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 -- / Alexander Bokovoy From tbordaz at redhat.com Mon Aug 8 14:55:26 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 8 Aug 2016 16:55:26 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <20160808142052.23rcbyd7llbljbfi@redhat.com> References: <20160808073457.vrcrunrodu5px433@redhat.com> <20160808083518.x2ose47ttuotcdsy@redhat.com> <20160808085100.GD7069@10.4.128.1> <20160808085623.daozgyxrlltzviuu@redhat.com> <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> Message-ID: <57A89D5E.60807@redhat.com> On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: > On Mon, 08 Aug 2016, thierry bordaz wrote: >> >> >> On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>> On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>> On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>> On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>> When SSSD resolves AD users on behalf of slapi-nis, it can >>>>>> accept any >>>>>>> user identifier, including user principal name (UPN) which may be >>>>>>> different than the canonical user name which SSSD returns. >>>>>>> >>>>>>> As result, the entry created by slapi-nis will be using >>>>>> canonical user >>>>>>> name but the filter for search will refer to the original (aliased) >>>>>>> name. The search will not match the newly created entry. >>>>>>> >>>>>>> The issue is fixed in slapi-nis-0.56.1 by returning two values for >>>>>>> 'uid' attribute: the canonical one and the aliased one. This way >>>>>>> the >>>>>>> search will match. >>>>>>> >>>>>>> Standard LDAP schema allows multiple values for 'uid' attribute. We >>>>>>> actually use the same trick for 'cn' attribute in the groups map >>>>>>> already. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/6138 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hello, >>>>>> >>>>>> should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>>>> No, this is not required. In Fedora we'll submit a combined update -- >>>>> I've built slapi-nis-0.56.1-1 packages for f24, f25, and rawhide >>>>> already >>>>> but did not submit a Bodhi request. >>>>> >>>> How is combined updated related to requires to slapi-nis-0.56.1? >>>> It will not prevent tu update freeipa without new slapi-nis. >>>> >>>> e.g. >>>> dnf update freeipa-server. >>> An update file in FreeIPA that is proposed by this patch does not >>> affect >>> operation of the older slapi-nis deployment once update is applied. >>> >> >> Hi, >> >> Is '%first' returning the first value of the attribute 'uid' ? >> If there are several values (canonical, alias,... ), does the order >> matters ? > We insert the canonical one first and it seems that 389-ds does not > change the order, at least in my tests. You can see the output in the > bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 From ldap pov (https://tools.ietf.org/html/rfc4511#section-4.1.7) the order of the values is not preserved. I think it is a bit risky to rely on a specific order especially with complex updates (adding several values in a single mod, replace) and replication. would it help to add canonical value with a subtype (e.g. 'uid;canonical: ') ? From abokovoy at redhat.com Mon Aug 8 15:20:07 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Aug 2016 18:20:07 +0300 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <57A89D5E.60807@redhat.com> References: <20160808073457.vrcrunrodu5px433@redhat.com> <20160808083518.x2ose47ttuotcdsy@redhat.com> <20160808085100.GD7069@10.4.128.1> <20160808085623.daozgyxrlltzviuu@redhat.com> <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> Message-ID: <20160808152007.v5fq23paiaa55khf@redhat.com> On Mon, 08 Aug 2016, thierry bordaz wrote: > > >On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>On Mon, 08 Aug 2016, thierry bordaz wrote: >>> >>> >>>On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>>On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>When SSSD resolves AD users on behalf of slapi-nis, it >>>>>>>>can >>>>>>>accept any >>>>>>>>user identifier, including user principal name (UPN) which may be >>>>>>>>different than the canonical user name which SSSD returns. >>>>>>>> >>>>>>>>As result, the entry created by slapi-nis will be using >>>>>>>canonical user >>>>>>>>name but the filter for search will refer to the original (aliased) >>>>>>>>name. The search will not match the newly created entry. >>>>>>>> >>>>>>>>The issue is fixed in slapi-nis-0.56.1 by returning two values for >>>>>>>>'uid' attribute: the canonical one and the aliased one. >>>>>>>>This way the >>>>>>>>search will match. >>>>>>>> >>>>>>>>Standard LDAP schema allows multiple values for 'uid' attribute. We >>>>>>>>actually use the same trick for 'cn' attribute in the groups map >>>>>>>>already. >>>>>>>> >>>>>>>>https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>Hello, >>>>>>> >>>>>>>should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>>>>>No, this is not required. In Fedora we'll submit a combined update -- >>>>>>I've built slapi-nis-0.56.1-1 packages for f24, f25, and >>>>>>rawhide already >>>>>>but did not submit a Bodhi request. >>>>>> >>>>>How is combined updated related to requires to slapi-nis-0.56.1? >>>>>It will not prevent tu update freeipa without new slapi-nis. >>>>> >>>>>e.g. >>>>>dnf update freeipa-server. >>>>An update file in FreeIPA that is proposed by this patch does >>>>not affect >>>>operation of the older slapi-nis deployment once update is applied. >>>> >>> >>>Hi, >>> >>>Is '%first' returning the first value of the attribute 'uid' ? >>>If there are several values (canonical, alias,... ), does the >>>order matters ? >>We insert the canonical one first and it seems that 389-ds does not >>change the order, at least in my tests. You can see the output in the >>bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 > >From ldap pov (https://tools.ietf.org/html/rfc4511#section-4.1.7) the >order of the values is not preserved. >I think it is a bit risky to rely on a specific order especially with >complex updates (adding several values in a single mod, replace) and >replication. >would it help to add canonical value with a subtype (e.g. >'uid;canonical: ') ? Not sure how what you are mention is relevant here. We talk about slapi-nis map cache entries which are not modified, replaced or replicated anywhere by anything other than slapi-nis itself. When entries are changed by slapi-nis, they are regenerated from scratch. Your worries do not apply here. -- / Alexander Bokovoy From tbordaz at redhat.com Mon Aug 8 15:30:06 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 8 Aug 2016 17:30:06 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <20160808152007.v5fq23paiaa55khf@redhat.com> References: <20160808073457.vrcrunrodu5px433@redhat.com> <20160808083518.x2ose47ttuotcdsy@redhat.com> <20160808085100.GD7069@10.4.128.1> <20160808085623.daozgyxrlltzviuu@redhat.com> <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> <20160808152007.v5fq23paiaa55khf@redhat.com> Message-ID: <57A8A57E.3070003@redhat.com> On 08/08/2016 05:20 PM, Alexander Bokovoy wrote: > On Mon, 08 Aug 2016, thierry bordaz wrote: >> >> >> On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>> >>>> >>>> On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>> On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>> On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>> On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>> When SSSD resolves AD users on behalf of slapi-nis, it can >>>>>>>> accept any >>>>>>>>> user identifier, including user principal name (UPN) which may be >>>>>>>>> different than the canonical user name which SSSD returns. >>>>>>>>> >>>>>>>>> As result, the entry created by slapi-nis will be using >>>>>>>> canonical user >>>>>>>>> name but the filter for search will refer to the original >>>>>>>>> (aliased) >>>>>>>>> name. The search will not match the newly created entry. >>>>>>>>> >>>>>>>>> The issue is fixed in slapi-nis-0.56.1 by returning two >>>>>>>>> values for >>>>>>>>> 'uid' attribute: the canonical one and the aliased one. This >>>>>>>>> way the >>>>>>>>> search will match. >>>>>>>>> >>>>>>>>> Standard LDAP schema allows multiple values for 'uid' >>>>>>>>> attribute. We >>>>>>>>> actually use the same trick for 'cn' attribute in the groups map >>>>>>>>> already. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>>>>>> No, this is not required. In Fedora we'll submit a combined >>>>>>> update -- >>>>>>> I've built slapi-nis-0.56.1-1 packages for f24, f25, and rawhide >>>>>>> already >>>>>>> but did not submit a Bodhi request. >>>>>>> >>>>>> How is combined updated related to requires to slapi-nis-0.56.1? >>>>>> It will not prevent tu update freeipa without new slapi-nis. >>>>>> >>>>>> e.g. >>>>>> dnf update freeipa-server. >>>>> An update file in FreeIPA that is proposed by this patch does not >>>>> affect >>>>> operation of the older slapi-nis deployment once update is applied. >>>>> >>>> >>>> Hi, >>>> >>>> Is '%first' returning the first value of the attribute 'uid' ? >>>> If there are several values (canonical, alias,... ), does the order >>>> matters ? >>> We insert the canonical one first and it seems that 389-ds does not >>> change the order, at least in my tests. You can see the output in the >>> bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 >> >> From ldap pov (https://tools.ietf.org/html/rfc4511#section-4.1.7) the >> order of the values is not preserved. >> I think it is a bit risky to rely on a specific order especially with >> complex updates (adding several values in a single mod, replace) and >> replication. >> would it help to add canonical value with a subtype (e.g. >> 'uid;canonical: ') ? > Not sure how what you are mention is relevant here. We talk about > slapi-nis map cache entries which are not modified, replaced or > replicated anywhere by anything other than slapi-nis itself. When > entries are changed by slapi-nis, they are regenerated from scratch. > > Your worries do not apply here. ok. I understand my mistake, I was thinking the compat entry had a associated real entry in ldap and this real entry had two uid values. From blipton at redhat.com Mon Aug 8 20:23:28 2016 From: blipton at redhat.com (Ben Lipton) Date: Mon, 8 Aug 2016 16:23:28 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <20160725111123.qthtarfgcsfbdnzk@redhat.com> <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> Message-ID: <57f0be1e-2915-fa33-d579-f173f1f5d019@redhat.com> On 07/25/2016 07:45 AM, Jan Cholasta wrote: > On 25.7.2016 13:11, Alexander Bokovoy wrote: >> On Mon, 25 Jul 2016, Jan Cholasta wrote: >>> On 20.7.2016 16:05, Ben Lipton wrote: >>>> Hi, >>>> >>>> Thanks very much for the feedback! Some responses below; I hope you'll >>>> let me know what you think of my reasoning. >>>> >>>> >>>> On 07/20/2016 04:20 AM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 17.6.2016 00:06, Ben Lipton wrote: >>>>>> On 06/14/2016 08:27 AM, Ben Lipton wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> I have written up a design proposal for making certificate requests >>>>>>> easier to generate when using alternate certificate profiles: >>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The use case for this is described in >>>>>>> https://fedorahosted.org/freeipa/ticket/4899. I will be working on >>>>>>> implementing this design over the next couple of months. If you >>>>>>> have >>>>>>> the time and interest, please take a look and share any comments or >>>>>>> concerns that you have. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Ben >>>>>>> >>>>>> Just a quick update to say that I've created a new document that >>>>>> covers >>>>>> the proposed schema additions in a more descriptive way (with >>>>>> diagrams!) >>>>>> I'm very new to developing with LDAP, so some more experienced >>>>>> eyes on >>>>>> the proposal would be very helpful, even if you don't have time to >>>>>> absorb the full design. Please take a look at >>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >>>>>> >>>>>> >>>>>> >>>>>> if you have a chance. >>>>> >>>>> I finally had a chance to take a look at this, here are some >>>>> comments: >>>>> >>>>> 1) I don't like how transformation rules are tied to a particular >>>>> helper and have to be duplicated for each of them. They should be >>>>> generic and work with any helper, as helpers are just an >>>>> implementation detail and their resulting data is the same. >>>>> >>>>> In fact, I think I would prefer if the CSR was generated using >>>>> python-cryptography's CertificateSigningRequestBuilder [1] rather >>>>> than >>>>> openssl or certutil or any other command line tool. >>>>> >>>> There are lots of tools that users might want to use to manage their >>>> private keys, so I don't know if we can assume that whatever >>>> library we >>>> prefer will actually be able to access the private key to sign a CSR, >>>> which is why I thought it would be useful to support more than one. >>> >>> python-cryptography has the notion of backends, which allow it to >>> support multiple crypto implementations. Upstream it currently >>> supports only OpenSSL [2], but some work has been done on PKCS#11 >>> backend [3], which provides support for HSMs and soft-tokens (like NSS >>> databases). >>> >>> Alternatively, for NSS databases (and other "simple" cases), you can >>> generate the private key with python-cryptography using the default >>> backend, export it to a file and import the file to the target >>> database, so you don't actually need the PKCS#11 backend for them. >>> >>> So, the only thing that's currently lacking is HSM support, but given >>> that we don't support HSMs in IPA nor in certmonger, I don't think >>> it's an issue for now. >>> >>>> The >>>> purpose of the mapping rule is to tie together the transformation >>>> rules >>>> that produce the same data into an object that's >>>> implementation-agnostic, so that profiles referencing those rules are >>>> automatically compatible with all the helper options. >>> >>> They are implementation-agnostic, as long as you consider `openssl` >>> and `certutil` the only implementations :-) But I don't think this >>> solution scales well to other possible implementations. >>> >>> Anyway, my main grudge is that the transformation rules shouldn't >>> really be stored on and processed by the server. The server should >>> know the *what* (mapping rules), but not the *how* (transformation >>> rules). The *how* is an implementation detail and does not change in >>> time, so there's no benefit in handling it on the server. It should be >>> handled exclusively on the client, which I believe would also make the >>> whole thing more robust (it would not be possible for a bug on the >>> server to break all the clients). >> This is a good point. However, for the scope of Ben's project can we >> limit it by openssl and certutil support? Otherwise Ben wouldn't be able >> to complete the project in time. > > I'm fine with that, but I don't think it's up to me :-) > >> >>>> This is turning out to be a common (and, I think, reasonable) reaction >>>> to the proposal. It is rather complex, and I worry that it will be >>>> difficult to configure. On the other hand, there is some hidden >>>> complexity to enabling a simpler config format, as well. One of the >>>> goals of the project as it was presented to me was to allow the >>>> creation >>>> of profiles that add certificate extensions *that FreeIPA doesn't yet >>>> know about*. With the current proposal, one only has to add a rule >>>> generating text that the helper will understand. >>> >>> ... which will be possible only as long as the helper understands the >>> extension. Which it might not, thus the current proposal works only >>> for *some* extensions that FreeIPA doesn't yet support. >> We can go ad infinitum here but with any helper implementation, be it >> python-cryptography or anything else, you will need to have a support >> there as well. > > My point was that the current proposal is not any better than my > proposal in this regard, as neither of them allows one to use an > arbitrary extension. > >> The idea with unknown extensions was to allow mapping >> their acceptance to a specific relationship between IPA objects >> (optionally) and an input from the CSR. A simplest example would be an >> identity rule that would copy an ASN.1 encoded content from the CSR to >> the certificate. >> >> That's on the mapping side, not on the CSR generation side, but it would >> go similarly for the CSR if you would be able to enter unknown but >> otherwise correct ASN.1 stream. There is no difference at which helper >> type we are talking about because all of them support inserting ASN.1 >> content. >> >>>> With your suggestion, >>>> if there's a mapping between "san_directoryname" and the corresponding >>>> API calls or configuration lines, we need some way for users to >>>> augment >>>> that mapping without changing the code. If there's no mapping, and >>>> it's >>>> just done with text processing, we need enough in the config format to >>>> be able to generate fairly complex structures: >>>> >>>> builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>>> builder = >>>> builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>>> >>>> >>>> x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False) >>>> >>>> and we need to do it without it being equivalent to calling eval() on >>>> the config attributes. I'm not sure how to achieve this (is it safe to >>>> call getattr(x509, extensiontype)(value) where extensiontype and value >>>> are user-specified?) and it definitely would have to be tied to a >>>> particular library/tool. >>> >>> As I pointed out above, this needs to be figured out for the generic >>> case for both the current proposal and my suggestion. I have a proof of concept[1] for using openssl-based rules to add a subject alt name extension without using openssl's knowledge of that extension. It's not extremely pretty, and it took some trial and error, but no code changes. So, I think this actually is a difference between the two proposals. Next we have the easy case, extensions that we as FreeIPA developers know are important and build support for. For these, the two proposals work equivalently well, but yours is simpler to configure because the knowledge of how to make a san_rfc822name is built into the library instead of being stored on the server as a set of rules. Finally, we have the case of extensions that are known to the helper, but not to FreeIPA. In the existing proposal, new rules can be written to support these extensions under a particular helper. Further, those rules can be used by reference in many profiles, reducing duplication of effort/data/errors. As I understand it, the main objections in this thread are that transformation rules are implementation (i.e. helper) specific data stored in the IPA server, and that the system has several levels of schema when it could just embed rules in the profile. But without helper-specific rules, administrators could not take advantage of the additional extensions supported by the helper they are using. And without the separation of profiles from mapping rules in the schema, rules would need to be copy+pasted among profiles, and grouping rules with the same effect under different helpers would be much uglier. We can and should discuss whether these are the right tradeoffs, but this is where those decisions came from. >>> >>> OTOH, I think we could use GSER encoding of the extension value: >>> >>> { rfc822Name:"user at example.com", >>> directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } >> GSER is not really used widely and does not have standardized encoding >> rules beyond its own definition. If you want to allow transformation >> rules in GSER that mention existing content in IPA objects, you would >> need to deal with templating anyway. At this point it becomes irrelevant >> what you are templating, though. > > True, but the goal here is not to avoid templating, but rather to > avoid implementation-specific bits on the server, and GSER is the only > thing that is textual, implementation-neutral and, as a bonus, > standardized. > As I said elsewhere, we could use GSER as a textual output format instead of openssl or certutil, but it still needs its own "helper" to build the CSR, and unlike the other options, it seems like we might need to implement that helper. I'm not sure it's fair to call it implementation-neutral if no implementation exists yet :) But, with sufficient time to do so, I would agree that building GSER support into python-cryptography or some other library could be an elegant way to abstract away the helper utilities. I think even in this environment the schema/syntax simplification you proposed would be problematic, as some of the reasons discussed above would still hold. [1] [root at vm-058-019 freeipa]# ipa certtransformationrule-show GenericSAN GenericSANOpenssl Certificate Transformation Rule ID: GenericSANOpenssl String defining the transformation: {% set extension = true %}2.5.29.17=ASN1:SEQUENCE:{% call openssl.section() %}{{ datarules|join(n) }}{% endcall %} Name of CSR generation helper: openssl [root at vm-058-019 freeipa]# ipa certtransformationrule-show GenericDNS GenericDNSOpenssl Certificate Transformation Rule ID: GenericDNSOpenssl String defining the transformation: dns=IMPLICIT:2,IA5STRING:{{ ipa.datafield(subject.krbprincipalname.0|safe_attr("hostname")) }} Name of CSR generation helper: openssl From ofayans at redhat.com Tue Aug 9 08:57:38 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 9 Aug 2016 10:57:38 +0200 Subject: [Freeipa-devel] [PATCH] ca-less tests updated In-Reply-To: <5731F951.1020700@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> <563C5B1A.1090803@redhat.com> <563C5E6D.4060307@redhat.com> <563CA575.1030808@redhat.com> <567176A2.1000901@redhat.com> <5707C431.6070702@redhat.com> <570E1E70.6060309@redhat.com> <5715F6B5.3070003@redhat.com> <57173F56.5020308@redhat.com> <5731F951.1020700@redhat.com> Message-ID: <57A99B02.1010507@redhat.com> Hi all, Bump for the review of the 0013 patch. The script it addresses can be reused in some WebUI tests - one more reason to have it reviewed/merged The rest patches should be re-tested, since they were prepared a good while ago On 05/10/2016 05:08 PM, Oleg Fayans wrote: > Hi David, > > After quite a while and some more struggles here comes the updated > version of the patch together with other patches fixing things in > ipatests/test_integration/tasks.py > Server and replica installation was refactored in a way to utilize the > code from tasks.py as much as it is possible > > The full set of necessary patches is attached > > > On 04/20/2016 10:35 AM, David Kupka wrote: >> On 19/04/16 11:13, Oleg Fayans wrote: >>> OK, that one, though passing lint, did not actually work. I gave up my >>> attempts to define method decorators inside the class. Now it passes >>> lint AND works:) >>> >> >> Hi Oleg! >> >> 1) Current commit message is useless. Please use it to describe what is >> the point of the patch. >> >> 2) $ git show -U0 | pep8 --diff >> ./ipatests/test_integration/test_caless.py:66:1: E302 expected 2 blank >> lines, found 1 >> ./ipatests/test_integration/test_caless.py:74:1: E302 expected 2 blank >> lines, found 1 >> ./ipatests/test_integration/test_caless.py:820:5: E303 too many blank >> lines (2) >> ./ipatests/test_integration/test_caless.py:825:80: E501 line too long >> (80 > 79 characters) >> ./ipatests/test_integration/test_caless.py:1035:44: E225 missing >> whitespace around operator >> >> >> 3) Isn't there a way to do this with pytest's fixtures? >> >>> +def server_install_teardown(func): >>> + def wrapped(*args): >>> + try: >>> + func(*args) >>> + finally: >>> + args[0].uninstall_server() >>> + return wrapped >>> + >>> +def replica_install_teardown(func): >>> + def wrapped(*args): >>> + try: >>> + func(*args) >>> + finally: >>> + # Uninstall replica >>> + replica = args[0].replicas[0] >>> + tasks.kinit_admin(args[0].master) >>> + args[0].uninstall_server(replica) >>> + args[0].master.run_command(['ipa-replica-manage', 'del', >>> + replica.hostname, '--force'], >>> + raiseonerr=False) >>> + args[0].master.run_command(['ipa', 'host-del', >>> + replica.hostname], >>> + raiseonerr=False) >>> + return wrapped >>> + > > There is a standard pytest method called 'method_teardown', that is > indent to be executed after each test method, but with our setup it does > not work. > >> >> 4) Is it necessary to create the $TEST_DIR in the test? Isn't it created >> by the framework? >> >>> + host.transport.mkdir_recursive(host.config.test_dir) >> > > Removed. > >> >> 5) I don't think the comment match the code. >> >>> >>> + # Remove CA cert in /etc/pki/nssdb, in case of failed >>> (un)install >>> + for host in cls.get_all_hosts(): >>> + cls.uninstall_server(host) >>> + >>> super(CALessBase, cls).uninstall(mh) >> > > Not actual anymore > >> >> 6) No! Create list with one element, iterate that list and append every >> item to the other list. Maybe there's better way (Hint: append). >> I've seen this on multiple places. >> >>> if unattended: >>> args.extend(['-U']) > > Agreed > >> >> 7) Why don't you (extend and) use >> ipatests.test_integaration.tasks.(un)install_{master,replica}? >> This could be done pretty much all over the code. >> >>> host.run_command(['ipa-server-install', '--uninstall', '-U']) >> >> 8) Use ipaplatform.paths for certutil and other binaries. If the binary >> is not there feel free to add it. >> I've seen this on multiple places. >> >>> + host.run_command(['certutil', '-d', paths.NSS_DB_DIR, '-D', >>> + '-n', 'External CA cert'], >>> + raiseonerr=False) >>> + # A workaround forhttps://fedorahosted.org/freeipa/ticket/4639 >>> + result = host.run_command(['certutil', '-L', '-d', >>> + paths.HTTPD_ALIAS_DIR]) >>> + for rawcert in result.stdout_text.split('\n')[4: -1]: >>> + cert = rawcert.split(' ')[0] >>> + host.run_command(['certutil', '-D', '-d', >>> paths.HTTPD_ALIAS_DIR, >>> + '-n', cert]) >>> > > Done > >> >> 9) certmonger is system service. You can check if is is .enabled() and >> .running(). And IIUC the comment is negation of what the code does. >> >>> >>> # Verify certmonger was not started >>> result = host.run_command(['getcert', 'list'], >>> raiseonerr=False) >>> - assert result > 0 >>> - assert ('Please verify that the certmonger service has >>> been ' >>> - 'started.' in result.stdout_text), >>> result.stdout_text >>> + assert result.returncode == 0 >> >> 10) What is the point of calling uninstall_server() when it will be >> called in the finally block of server_install_teardown anyway? >> >>> + @server_install_teardown >>> def test_revoked_http(self): >>> "IPA server install with revoked HTTP certificate" >>> >>> if result.returncode == 0: >>> + self.uninstall_server() >>> raise nose.SkipTest( >>> "Known CA-less installation defect, see " >>> +"https://fedorahosted.org/freeipa/ticket/4270") >>> >>> assert result.returncode > 0 >>> > Removed > >> >> Nitpick) Do not mix fixing typos/grammar/spelling/style with functional >> changes. >> >>> - def test_incorect_http_pin(self): >>> + @pytest.mark.xfail(reason='freeipa ticket 5378') >>> + def test_incorrect_http_pin(self): >>> "Install new HTTP certificate with incorrect PKCS#12 password" > > Removed > >> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Tue Aug 9 10:37:20 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 12:37:20 +0200 Subject: [Freeipa-devel] [PATCH 0561] backup: backup /etc/tmpfiles.d/dirsrv-instance-* Message-ID: https://fedorahosted.org/freeipa/ticket/6165 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0561-ipa-backup-backup-etc-tmpfiles.d-dirsrv-instance-.co.patch Type: text/x-patch Size: 2145 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 9 10:49:47 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 12:49:47 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <57A8A57E.3070003@redhat.com> References: <20160808073457.vrcrunrodu5px433@redhat.com> <20160808083518.x2ose47ttuotcdsy@redhat.com> <20160808085100.GD7069@10.4.128.1> <20160808085623.daozgyxrlltzviuu@redhat.com> <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> <20160808152007.v5fq23paiaa55khf@redhat.com> <57A8A57E.3070003@redhat.com> Message-ID: On 08.08.2016 17:30, thierry bordaz wrote: > > > On 08/08/2016 05:20 PM, Alexander Bokovoy wrote: >> On Mon, 08 Aug 2016, thierry bordaz wrote: >>> >>> >>> On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>> >>>>> >>>>> On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>>> On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>>> On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>>> On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>>> When SSSD resolves AD users on behalf of slapi-nis, it can >>>>>>>>> accept any >>>>>>>>>> user identifier, including user principal name (UPN) which >>>>>>>>>> may be >>>>>>>>>> different than the canonical user name which SSSD returns. >>>>>>>>>> >>>>>>>>>> As result, the entry created by slapi-nis will be using >>>>>>>>> canonical user >>>>>>>>>> name but the filter for search will refer to the original >>>>>>>>>> (aliased) >>>>>>>>>> name. The search will not match the newly created entry. >>>>>>>>>> >>>>>>>>>> The issue is fixed in slapi-nis-0.56.1 by returning two >>>>>>>>>> values for >>>>>>>>>> 'uid' attribute: the canonical one and the aliased one. This >>>>>>>>>> way the >>>>>>>>>> search will match. >>>>>>>>>> >>>>>>>>>> Standard LDAP schema allows multiple values for 'uid' >>>>>>>>>> attribute. We >>>>>>>>>> actually use the same trick for 'cn' attribute in the groups map >>>>>>>>>> already. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>>>>>>> No, this is not required. In Fedora we'll submit a combined >>>>>>>> update -- >>>>>>>> I've built slapi-nis-0.56.1-1 packages for f24, f25, and >>>>>>>> rawhide already >>>>>>>> but did not submit a Bodhi request. >>>>>>>> >>>>>>> How is combined updated related to requires to slapi-nis-0.56.1? >>>>>>> It will not prevent tu update freeipa without new slapi-nis. >>>>>>> >>>>>>> e.g. >>>>>>> dnf update freeipa-server. >>>>>> An update file in FreeIPA that is proposed by this patch does not >>>>>> affect >>>>>> operation of the older slapi-nis deployment once update is applied. >>>>>> >>>>> >>>>> Hi, >>>>> >>>>> Is '%first' returning the first value of the attribute 'uid' ? >>>>> If there are several values (canonical, alias,... ), does the >>>>> order matters ? >>>> We insert the canonical one first and it seems that 389-ds does not >>>> change the order, at least in my tests. You can see the output in the >>>> bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 >>> >>> From ldap pov (https://tools.ietf.org/html/rfc4511#section-4.1.7) >>> the order of the values is not preserved. >>> I think it is a bit risky to rely on a specific order especially >>> with complex updates (adding several values in a single mod, >>> replace) and replication. >>> would it help to add canonical value with a subtype (e.g. >>> 'uid;canonical: ') ? >> Not sure how what you are mention is relevant here. We talk about >> slapi-nis map cache entries which are not modified, replaced or >> replicated anywhere by anything other than slapi-nis itself. When >> entries are changed by slapi-nis, they are regenerated from scratch. >> >> Your worries do not apply here. > ok. > I understand my mistake, I was thinking the compat entry had a > associated real entry in ldap and this real entry had two uid values. > So, could you provide ack thierry? Martin From mbasti at redhat.com Tue Aug 9 11:00:53 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 13:00:53 +0200 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: <9001af3d-2831-6c3c-141d-941656bcbe94@redhat.com> References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> <57A0B845.5000105@redhat.com> <02645dd8-7a5d-9201-0a28-498de56dd9ab@redhat.com> <9001af3d-2831-6c3c-141d-941656bcbe94@redhat.com> Message-ID: <52e0d59b-71b0-72b4-a69e-4ce3e68d5289@redhat.com> On 05.08.2016 16:44, Martin Basti wrote: > > > > On 02.08.2016 18:08, Pavel Vomacka wrote: >> >> On 08/02/2016 05:31 PM, Pavel Vomacka wrote: >>> >>> >>> On 08/02/2016 05:27 PM, Martin Basti wrote: >>>> >>>> >>>> On 02.08.2016 17:12, Rob Crittenden wrote: >>>>> Pavel Vomacka wrote: >>>>>> Hello, >>>>>> >>>>>> please review attached patches which Split make lint to more >>>>>> targets and >>>>>> add jslint >>>>> >>>>> What's the driver to split the checks out into separate targets? >>>> >>>> It is called several times during build (makes build slower), and >>>> you cannot run `make clean` in case you have wrong API.txt, because >>>> it will explode >>> Yes, definitely. >> So I removed moving the aci and api checks and just add jslint. >>>>> >>>>> You are moving the makeapi and makeaci from version-update to >>>>> lint. They were in version-update for a reason: downstream builds >>>>> do not call lint. Downstream may patch code. API cannot break. >>>> Can we update downstream spec then? >>>> >>>>> >>>>> No ticket? >>>> Pavel please file tickets. >>>> >>> Yes, I will file tickets for these changes. >> Also ticket is now filed: >> >> https://fedorahosted.org/freeipa/ticket/6161 >>>>> >>>>> rob >>>>> >>>> Martin^2 >>>> >>> >> >> >> > > ACK 0098-2: works for me > > Martin^2 > > Pushed to master: 58da5fb4b9e81e872e0b59c17263071f8b2889da -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 9 11:07:14 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 13:07:14 +0200 Subject: [Freeipa-devel] [PATCH 0032] Secure permission and cleanup Custodia server.keys In-Reply-To: References: <5159a7b0-7942-3a8b-ff16-94925488f303@redhat.com> <72042d4c-cd89-b30c-dc35-679360d96e0c@redhat.com> Message-ID: <2282f59a-4aae-021c-67a0-278e19fac196@redhat.com> On 03.08.2016 20:21, Martin Basti wrote: > > > > On 03.08.2016 19:18, Martin Basti wrote: >> >> >> >> On 02.08.2016 20:02, Christian Heimes wrote: >>> On 2016-07-19 17:03, Martin Basti wrote: >>>> On 12.07.2016 16:45, Christian Heimes wrote: >>>>> Custodia's server.keys file contain the private RSA keys for encrypting >>>>> and signing Custodia messages. The file was created with permission 644 >>>>> and is only secured by permission 700 of the directory >>>>> /etc/ipa/custodia. The installer and upgrader ensure that the file >>>>> has 600. >>>>> >>>>> The server.keys file and all keys are now removed when during >>>>> uninstallation of a server, too. >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1353936 >>>>> https://fedorahosted.org/freeipa/ticket/6015 >>>>> https://fedorahosted.org/freeipa/ticket/6056 >>>>> >>>>> >>>> NACK >>>> >>>> ipa-server-install --uninstall doesn't work >>> I fixed it by splitting up uninstallation into two parts: >>> >>> 1) the server_del plugin takes care of the LDAP entries >>> 2) CustodiaInstance.uninstall() removes the local key file >>> >> >> Hello, >> >> 1) >> Is expected that after removing replica, ipa server-del >> vm-012.abc.idm.lab.eng.brq.redhat.com, I have these entries in LDAP >> on master (vm-058-107)? >> >> # sig/vm-012.abc.idm.lab.eng.brq.redhat.com, custodia, ipa, etc, >> abc.idm.lab.en >> g.brq.redhat.com >> dn: >> cn=sig/vm-012.abc.idm.lab.eng.brq.redhat.com,cn=custodia,cn=ipa,cn=etc,dc= >> abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> objectClass: nsContainer >> objectClass: ipaKeyPolicy >> objectClass: ipaPublicKeyObject >> objectClass: groupOfPrincipals >> objectClass: top >> cn: sig/vm-012.abc.idm.lab.eng.brq.redhat.com >> ipaKeyUsage: digitalSignature >> memberPrincipal: >> host/vm-012.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BR >> Q.REDHAT.COM >> ipaPublicKey:: >> MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqV4NGWu8224ar3IdwlD >> cOpNBjcQKY0gznMuAjlikHKxnpfzmGCf/GYxfealet64ek3RE3oLmYhITqX3NkLKw51KhuwGcEw31 >> hBa6YB/6uzx3tr/ruO++vk+U7Myz4eFzp7+Zryjk7ohVb3w/XhBcVbC+d9qyKGzM0OUaQgGOjy7eq >> 3tiI+VugfyawvAvItCwyo56R8fO1jS1uKA+NDz5ltIymE9sySpVWfTMhCDUEjy9iEMiPixtiyVbHd >> g8A80H7W4fe7mTcqkKPD6sfYr2QwKh4pF7wU+RHfXsoXIu5gYNPgxdsHd/1p914EQ9U6RYTFsSEzk >> DR8V2H1rJ0AiVPQIDAQAB >> >> # enc/vm-012.abc.idm.lab.eng.brq.redhat.com, custodia, ipa, etc, >> abc.idm.lab.en >> g.brq.redhat.com >> dn: >> cn=enc/vm-012.abc.idm.lab.eng.brq.redhat.com,cn=custodia,cn=ipa,cn=etc,dc= >> abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> objectClass: nsContainer >> objectClass: ipaKeyPolicy >> objectClass: ipaPublicKeyObject >> objectClass: groupOfPrincipals >> objectClass: top >> cn: enc/vm-012.abc.idm.lab.eng.brq.redhat.com >> ipaKeyUsage: dataEncipherment >> memberPrincipal: >> host/vm-012.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BR >> Q.REDHAT.COM >> ipaPublicKey:: >> MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5vdu9LLl7Pa+cN+ivNO >> eOon1BOI3bbBzYAu8+l1ch8iepKJrom4O5yYT7qhz5aYgq4Pd2kuxuvcuf3OlGTizuKlqRELbVnG0 >> ogWN/YAqPExS6L2hEHcyIZTiOQk19jT/ynEqayjH/OM499aE1H3vc7FD30Cy9wBQNUzYuY8pWpaWd >> Jj8nbvEKLX7JYPSx5/3Bqx+tqK5ApAGutJ6lF3+9acuG6ADVwUY3hAqXcqu4Oy463LKIhdatqMv2r >> j0FEFHJYPG2GTOIhFF8jee2Q7iidgPNdfbvKCYbnAkXtT73hxJWTckoupGHpUo+5b/wl8pI1Lxhyz >> TIp7oPmFWMG/q1QIDAQAB >> >> Also see them on replica as well (which was removed from topology) >> I did not find any errors in http log >> >> 2) >> I tried hard, but I cannot see relation between >> https://fedorahosted.org/freeipa/ticket/6015 and >> https://fedorahosted.org/freeipa/ticket/6056 >> IMO it should be separated into two patches, to make easier >> backports, patching and make life easier in future with git blame >> >> There should not be a BZ, only upstream tickets in commit >> >> 3) >> IMO ti should be 'Removing' not 'Remove', I'm not native speaker, but >> it looks more consistent with the rest of log entries >> >> INFO Remove Custodia keys >> >> 4) >> the same for >> root_logger.info("Secure server.keys mode"), IMHO it should be 'Securing' >> >> 5) >> What is the purpose of remove_server_keys() in KEM.py . I see usage >> only in manual testing. Can it be reused in server.py ? Because it >> looks like duplicated code for me, but correct me if I'm wrong. >> >> Martin^2 >> >> >> >> >> > > I received this when I tried to uninstall already uninstalled replica > (calling ipa-replica-install -U --uninstall twice) > > 2016-08-03T17:45:13Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2016-08-03T17:45:13Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2016-08-03T17:45:13Z INFO Remove Custodia keys > 2016-08-03T17:45:13Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", > line 91, in _handle_exception > super(Continuous, self)._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 446, in _handle_exception > super(ComponentBase, self)._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 362, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", > line 71, in _uninstall > for nothing in self._uninstaller(self.parent): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", > line 1375, in main > uninstall(self) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", > line 266, in decorated > func(installer) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", > line 1076, in uninstall > custodiainstance.CustodiaInstance().uninstall() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", > line 88, in uninstall > self.__remove_keys() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", > line 72, in __remove_keys > keystore = IPAKEMKeys({'server_keys': self.server_keys}) > File "/usr/lib/python2.7/site-packages/ipapython/secrets/kem.py", > line 193, in __init__ > self.host = conf.get('global', 'host') > File "/usr/lib64/python2.7/ConfigParser.py", line 607, in get > raise NoSectionError(section) > NoSectionError: No section: 'global' > > > Please unfollow this thread, separated patches were send in new threads. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Tue Aug 9 11:24:20 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 9 Aug 2016 13:24:20 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: References: <20160808073457.vrcrunrodu5px433@redhat.com> <20160808083518.x2ose47ttuotcdsy@redhat.com> <20160808085100.GD7069@10.4.128.1> <20160808085623.daozgyxrlltzviuu@redhat.com> <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> <20160808152007.v5fq23paiaa55khf@redhat.com> <57A8A57E.3070003@redhat.com> Message-ID: <57A9BD64.5050308@redhat.com> On 08/09/2016 12:49 PM, Martin Basti wrote: > > > On 08.08.2016 17:30, thierry bordaz wrote: >> >> >> On 08/08/2016 05:20 PM, Alexander Bokovoy wrote: >>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>> >>>> >>>> On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>> >>>>>> >>>>>> On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>>>> On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>>>> On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>>>> On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>>>> When SSSD resolves AD users on behalf of slapi-nis, it can >>>>>>>>>> accept any >>>>>>>>>>> user identifier, including user principal name (UPN) which >>>>>>>>>>> may be >>>>>>>>>>> different than the canonical user name which SSSD returns. >>>>>>>>>>> >>>>>>>>>>> As result, the entry created by slapi-nis will be using >>>>>>>>>> canonical user >>>>>>>>>>> name but the filter for search will refer to the original >>>>>>>>>>> (aliased) >>>>>>>>>>> name. The search will not match the newly created entry. >>>>>>>>>>> >>>>>>>>>>> The issue is fixed in slapi-nis-0.56.1 by returning two >>>>>>>>>>> values for >>>>>>>>>>> 'uid' attribute: the canonical one and the aliased one. This >>>>>>>>>>> way the >>>>>>>>>>> search will match. >>>>>>>>>>> >>>>>>>>>>> Standard LDAP schema allows multiple values for 'uid' >>>>>>>>>>> attribute. We >>>>>>>>>>> actually use the same trick for 'cn' attribute in the groups >>>>>>>>>>> map >>>>>>>>>>> already. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>>>>>>>> No, this is not required. In Fedora we'll submit a combined >>>>>>>>> update -- >>>>>>>>> I've built slapi-nis-0.56.1-1 packages for f24, f25, and >>>>>>>>> rawhide already >>>>>>>>> but did not submit a Bodhi request. >>>>>>>>> >>>>>>>> How is combined updated related to requires to slapi-nis-0.56.1? >>>>>>>> It will not prevent tu update freeipa without new slapi-nis. >>>>>>>> >>>>>>>> e.g. >>>>>>>> dnf update freeipa-server. >>>>>>> An update file in FreeIPA that is proposed by this patch does >>>>>>> not affect >>>>>>> operation of the older slapi-nis deployment once update is applied. >>>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Is '%first' returning the first value of the attribute 'uid' ? >>>>>> If there are several values (canonical, alias,... ), does the >>>>>> order matters ? >>>>> We insert the canonical one first and it seems that 389-ds does not >>>>> change the order, at least in my tests. You can see the output in the >>>>> bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 >>>> >>>> From ldap pov (https://tools.ietf.org/html/rfc4511#section-4.1.7) >>>> the order of the values is not preserved. >>>> I think it is a bit risky to rely on a specific order especially >>>> with complex updates (adding several values in a single mod, >>>> replace) and replication. >>>> would it help to add canonical value with a subtype (e.g. >>>> 'uid;canonical: ') ? >>> Not sure how what you are mention is relevant here. We talk about >>> slapi-nis map cache entries which are not modified, replaced or >>> replicated anywhere by anything other than slapi-nis itself. When >>> entries are changed by slapi-nis, they are regenerated from scratch. >>> >>> Your worries do not apply here. >> ok. >> I understand my mistake, I was thinking the compat entry had a >> associated real entry in ldap and this real entry had two uid values. >> > > So, could you provide ack thierry? > > Martin Sure but I would have to test first :-) Alexander, how can I test this ? thanks thierry From pvomacka at redhat.com Tue Aug 9 11:29:43 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 9 Aug 2016 13:29:43 +0200 Subject: [Freeipa-devel] [PATCH] webui: 0084, 0101: refactoring rpc module Message-ID: Hello, please review attached patches. The rpc module is now separated from display layer and changing activity text while loading metadata. https://fedorahosted.org/freeipa/ticket/6144 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0084-Refactoring-of-rpc-module.patch Type: text/x-patch Size: 20667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0101-Change-activity-text-while-loading-metadata.patch Type: text/x-patch Size: 4548 bytes Desc: not available URL: From abokovoy at redhat.com Tue Aug 9 11:38:03 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 9 Aug 2016 14:38:03 +0300 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <57A9BD64.5050308@redhat.com> References: <20160808083518.x2ose47ttuotcdsy@redhat.com> <20160808085100.GD7069@10.4.128.1> <20160808085623.daozgyxrlltzviuu@redhat.com> <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> <20160808152007.v5fq23paiaa55khf@redhat.com> <57A8A57E.3070003@redhat.com> <57A9BD64.5050308@redhat.com> Message-ID: <20160809113803.2jehpfuxnrg4wozr@redhat.com> On Tue, 09 Aug 2016, thierry bordaz wrote: > > >On 08/09/2016 12:49 PM, Martin Basti wrote: >> >> >>On 08.08.2016 17:30, thierry bordaz wrote: >>> >>> >>>On 08/08/2016 05:20 PM, Alexander Bokovoy wrote: >>>>On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>> >>>>> >>>>>On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>>>>>On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>> >>>>>>> >>>>>>>On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>>>>>On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>>>>>On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>>>>>On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>>>>>When SSSD resolves AD users on behalf of slapi-nis, it can >>>>>>>>>>>accept any >>>>>>>>>>>>user identifier, including user principal name >>>>>>>>>>>>(UPN) which may be >>>>>>>>>>>>different than the canonical user name which SSSD returns. >>>>>>>>>>>> >>>>>>>>>>>>As result, the entry created by slapi-nis will be using >>>>>>>>>>>canonical user >>>>>>>>>>>>name but the filter for search will refer to the >>>>>>>>>>>>original (aliased) >>>>>>>>>>>>name. The search will not match the newly created entry. >>>>>>>>>>>> >>>>>>>>>>>>The issue is fixed in slapi-nis-0.56.1 by >>>>>>>>>>>>returning two values for >>>>>>>>>>>>'uid' attribute: the canonical one and the >>>>>>>>>>>>aliased one. This way the >>>>>>>>>>>>search will match. >>>>>>>>>>>> >>>>>>>>>>>>Standard LDAP schema allows multiple values for >>>>>>>>>>>>'uid' attribute. We >>>>>>>>>>>>actually use the same trick for 'cn' attribute >>>>>>>>>>>>in the groups map >>>>>>>>>>>>already. >>>>>>>>>>>> >>>>>>>>>>>>https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>Hello, >>>>>>>>>>> >>>>>>>>>>>should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>>>>>>>>>No, this is not required. In Fedora we'll submit a >>>>>>>>>>combined update -- >>>>>>>>>>I've built slapi-nis-0.56.1-1 packages for f24, f25, >>>>>>>>>>and rawhide already >>>>>>>>>>but did not submit a Bodhi request. >>>>>>>>>> >>>>>>>>>How is combined updated related to requires to slapi-nis-0.56.1? >>>>>>>>>It will not prevent tu update freeipa without new slapi-nis. >>>>>>>>> >>>>>>>>>e.g. >>>>>>>>>dnf update freeipa-server. >>>>>>>>An update file in FreeIPA that is proposed by this patch >>>>>>>>does not affect >>>>>>>>operation of the older slapi-nis deployment once update is applied. >>>>>>>> >>>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>Is '%first' returning the first value of the attribute 'uid' ? >>>>>>>If there are several values (canonical, alias,... ), does >>>>>>>the order matters ? >>>>>>We insert the canonical one first and it seems that 389-ds does not >>>>>>change the order, at least in my tests. You can see the output in the >>>>>>bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 >>>>> >>>>>From ldap pov >>>>>(https://tools.ietf.org/html/rfc4511#section-4.1.7) the order >>>>>of the values is not preserved. >>>>>I think it is a bit risky to rely on a specific order >>>>>especially with complex updates (adding several values in a >>>>>single mod, replace) and replication. >>>>>would it help to add canonical value with a subtype (e.g. >>>>>'uid;canonical: ') ? >>>>Not sure how what you are mention is relevant here. We talk about >>>>slapi-nis map cache entries which are not modified, replaced or >>>>replicated anywhere by anything other than slapi-nis itself. When >>>>entries are changed by slapi-nis, they are regenerated from scratch. >>>> >>>>Your worries do not apply here. >>>ok. >>>I understand my mistake, I was thinking the compat entry had a >>>associated real entry in ldap and this real entry had two uid >>>values. >>> >> >>So, could you provide ack thierry? >> >>Martin > >Sure but I would have to test first :-) > >Alexander, how can I test this ? slapi-nis 0.56.1-1 packages are available in koji for f24-f26: http://koji.fedoraproject.org/koji/packageinfo?packageID=6609 -- / Alexander Bokovoy From mbasti at redhat.com Tue Aug 9 11:53:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 13:53:29 +0200 Subject: [Freeipa-devel] [PATCH 0034] Secure permissions of Custodia server.keys In-Reply-To: <164526c4-5b07-669f-3887-0f5772d348a7@redhat.com> References: <164526c4-5b07-669f-3887-0f5772d348a7@redhat.com> Message-ID: <83082726-8ced-5334-2115-436106970244@redhat.com> On 08.08.2016 16:09, Christian Heimes wrote: > I have split up patch 0032 into two smaller patches. This patch only > addresses the server.keys file. > > Custodia's server.keys file contain the private RSA keys for encrypting > and signing Custodia messages. The file was created with permission 644 > and is only secured by permission 700 of the directory > /etc/ipa/custodia. The installer and upgrader ensure that the file > has 600. > > https://bugzilla.redhat.com/show_bug.cgi?id=1353936 > https://fedorahosted.org/freeipa/ticket/6056 > > Pylint is running, please wait ... ************* Module ipapython.secrets.kem ipapython/secrets/kem.py:147: [E0602(undefined-variable), newServerKeys] Undefined variable 'os') ipapython/secrets/kem.py:148: [E0602(undefined-variable), newServerKeys] Undefined variable 'os') ************* Module ipaserver.install.custodiainstance ipaserver/install/custodiainstance.py:77: [E0602(undefined-variable), CustodiaInstance.upgrade_instance] Undefined variable 'stat') -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Aug 9 11:59:43 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 9 Aug 2016 14:59:43 +0300 Subject: [Freeipa-devel] [PATCH] ipa-kdb: Allow to build with samba 4.5 In-Reply-To: <20160805070126.GA29546@10.4.128.1> References: <20160805070126.GA29546@10.4.128.1> Message-ID: <20160809115943.3teogq4gf2ltss36@redhat.com> On Fri, 05 Aug 2016, Lukas Slebodnik wrote: >ehlo, > >attached patches fix a build of freeipa on fedora 25 and fedora rawhide. >IMHO, this change in krb5pac.h is an ABI change and samba guys should >also bump a SONAME to related (private?) libraries. I could not see it; >but maybe I overlooked it. It an interesting question which you might raise upstream. krb5pac.h is auto-generated from krb5pac.idl, the same happens for all IDL-based definitions. They are not versioned, though. As for the patch, ACK. The change came with 4406cf792a599724f55777a45efb6367a9bd92b2, 'krb5pac.idl: introduce PAC_DOMAIN_GROUP_MEMBERSHIP to handle the resource groups' which landed upstream in May 2016. > >LS >>From 02db5adc82c36592f8aef5fd4d5e2f2e27f15b11 Mon Sep 17 00:00:00 2001 >From: Lukas Slebodnik >Date: Fri, 5 Aug 2016 08:29:27 +0200 >Subject: [PATCH 1/2] ipa-kdb: Allow to build with samba 4.5 > >daemons/ipa-kdb/ipa_kdb_mspac.c: In function 'filter_logon_info': >daemons/ipa-kdb/ipa_kdb_mspac.c:1536:19: error: 'struct PAC_LOGON_INFO' > has no member named 'res_group_dom_sid' > if (info->info->res_group_dom_sid != NULL && > ^~ >daemons/ipa-kdb/ipa_kdb_mspac.c:1537:19: error: 'struct PAC_LOGON_INFO' > has no member named 'res_groups'; did you mean 'resource_groups'? > info->info->res_groups.count != 0) { > ^~ >mv -f .deps/ipa_kdb_delegation.Tpo .deps/ipa_kdb_delegation.Plo >Makefile:806: recipe for target 'ipa_kdb_mspac.lo' failed >make[3]: *** [ipa_kdb_mspac.lo] Error 1 >make[3]: *** Waiting for unfinished jobs.... > >Related change in samba >https://github.com/samba-team/samba/commit/4406cf792a599724f55777a45efb6367a9bd92b2 > >Resolves: >https://fedorahosted.org/freeipa/ticket/6173 >--- > daemons/configure.ac | 12 ++++++++++++ > daemons/ipa-kdb/ipa_kdb_mspac.c | 9 +++++++++ > 2 files changed, 21 insertions(+) > >diff --git a/daemons/configure.ac b/daemons/configure.ac >index 94d66d813728fe4e32f9e3c0eef920d8e2395d8f..5c5a1046397aa97ba18cafc1b81dc2a6fb2dfd34 100644 >--- a/daemons/configure.ac >+++ b/daemons/configure.ac >@@ -170,6 +170,18 @@ PKG_CHECK_MODULES([SAMBAUTIL], [samba-util]) > SAMBA40EXTRA_LIBPATH="-L`$PKG_CONFIG --variable=libdir samba-util`/samba -Wl,-rpath=`$PKG_CONFIG --variable=libdir samba-util`/samba" > AC_SUBST(SAMBA40EXTRA_LIBPATH) > >+bck_cflags="$CFLAGS" >+CFLAGS="$NDRPAC_CFLAGS" >+AC_CHECK_MEMBER( >+ [struct PAC_DOMAIN_GROUP_MEMBERSHIP.domain_sid], >+ [AC_DEFINE([HAVE_STRUCT_PAC_DOMAIN_GROUP_MEMBERSHIP], [1], >+ [struct PAC_DOMAIN_GROUP_MEMBERSHIP is available.])], >+ [AC_MSG_NOTICE([struct PAC_DOMAIN_GROUP_MEMBERSHIP is not available])], >+ [[#include >+ #include ]]) >+ >+CFLAGS="$bck_cflags" >+ > LIBPDB_NAME="" > AC_CHECK_LIB([samba-passdb], > [make_pdb_method], >diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c >index 80e7055fd6cd7b962eeffbccc675a73d73700793..65cc03565dc06d1052c6acd0c0d6ee7265b37b36 100644 >--- a/daemons/ipa-kdb/ipa_kdb_mspac.c >+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >@@ -20,6 +20,8 @@ > * along with this program. If not, see . > */ > >+#include "config.h" >+ > #include "ipa_kdb.h" > #include "ipa_mspac.h" > #include >@@ -1533,10 +1535,17 @@ krb5_error_code filter_logon_info(krb5_context context, > > /* According to MS-KILE, ResourceGroups must be zero, so check > * that it is the case here */ >+#ifdef HAVE_STRUCT_PAC_DOMAIN_GROUP_MEMBERSHIP >+ if (info->info->resource_groups.domain_sid != NULL && >+ info->info->resource_groups.groups.count != 0) { >+ return EINVAL; >+ } >+#else > if (info->info->res_group_dom_sid != NULL && > info->info->res_groups.count != 0) { > return EINVAL; > } >+#endif > > return 0; > } >-- >2.9.2 > >>From 7d064bc2dda88552f597c1e8dfa2cf176a89ac77 Mon Sep 17 00:00:00 2001 >From: Lukas Slebodnik >Date: Fri, 5 Aug 2016 08:34:23 +0200 >Subject: [PATCH 2/2] ipa-kdb: Fix unit test after packaging changes in krb5 > >Resolves: >https://fedorahosted.org/freeipa/ticket/6173 >--- > freeipa.spec.in | 2 ++ > 1 file changed, 2 insertions(+) > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index 135e9c980011c6c2730c6c29a3c22098e48270d5..7b5bb906ea541da10e0a9f5f9970f5937728ee11 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -108,6 +108,8 @@ BuildRequires: python-netifaces >= 0.10.4 > # Build dependencies for unit tests > BuildRequires: libcmocka-devel > BuildRequires: nss_wrapper >+# Required by ipa_kdb_tests >+BuildRequires: %{_libdir}/krb5/plugins/kdb/db2.so > > %if 0%{?with_python3} > BuildRequires: python3-devel >-- >2.9.2 > >-- >Manage your subscription for the Freeipa-devel mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-devel >Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- / Alexander Bokovoy From jcholast at redhat.com Tue Aug 9 12:16:41 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 9 Aug 2016 14:16:41 +0200 Subject: [Freeipa-devel] [PATCH 686] Revert "spec: add conflict with bind-chroot to freeipa-server-dns" Message-ID: Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-686-Revert-spec-add-conflict-with-bind-chroot-to-freeipa.patch Type: text/x-patch Size: 1078 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 9 12:39:09 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 14:39:09 +0200 Subject: [Freeipa-devel] [PATCH] ipa-kdb: Allow to build with samba 4.5 In-Reply-To: <20160809115943.3teogq4gf2ltss36@redhat.com> References: <20160805070126.GA29546@10.4.128.1> <20160809115943.3teogq4gf2ltss36@redhat.com> Message-ID: <5020f05b-a1ca-e432-6595-f2fe762d4f77@redhat.com> On 09.08.2016 13:59, Alexander Bokovoy wrote: > On Fri, 05 Aug 2016, Lukas Slebodnik wrote: >> ehlo, >> >> attached patches fix a build of freeipa on fedora 25 and fedora rawhide. >> IMHO, this change in krb5pac.h is an ABI change and samba guys should >> also bump a SONAME to related (private?) libraries. I could not see it; >> but maybe I overlooked it. > It an interesting question which you might raise upstream. krb5pac.h is > auto-generated from krb5pac.idl, the same happens for all IDL-based > definitions. They are not versioned, though. > > As for the patch, ACK. The change came with > 4406cf792a599724f55777a45efb6367a9bd92b2, > 'krb5pac.idl: introduce PAC_DOMAIN_GROUP_MEMBERSHIP to handle the > resource groups' > which landed upstream in May 2016. master: * e7480bed277e441abf4cfdb1dd8c11471514c8ab ipa-kdb: Allow to build with samba 4.5 * 5fece5ff17fa5c2deead3d44953c512b7060f6ca ipa-kdb: Fix unit test after packaging changes in krb5 > >> >> LS > >>> From 02db5adc82c36592f8aef5fd4d5e2f2e27f15b11 Mon Sep 17 00:00:00 2001 >> From: Lukas Slebodnik >> Date: Fri, 5 Aug 2016 08:29:27 +0200 >> Subject: [PATCH 1/2] ipa-kdb: Allow to build with samba 4.5 >> >> daemons/ipa-kdb/ipa_kdb_mspac.c: In function 'filter_logon_info': >> daemons/ipa-kdb/ipa_kdb_mspac.c:1536:19: error: 'struct PAC_LOGON_INFO' >> has no member named 'res_group_dom_sid' >> if (info->info->res_group_dom_sid != NULL && >> ^~ >> daemons/ipa-kdb/ipa_kdb_mspac.c:1537:19: error: 'struct PAC_LOGON_INFO' >> has no member named 'res_groups'; did you mean 'resource_groups'? >> info->info->res_groups.count != 0) { >> ^~ >> mv -f .deps/ipa_kdb_delegation.Tpo .deps/ipa_kdb_delegation.Plo >> Makefile:806: recipe for target 'ipa_kdb_mspac.lo' failed >> make[3]: *** [ipa_kdb_mspac.lo] Error 1 >> make[3]: *** Waiting for unfinished jobs.... >> >> Related change in samba >> https://github.com/samba-team/samba/commit/4406cf792a599724f55777a45efb6367a9bd92b2 >> >> >> Resolves: >> https://fedorahosted.org/freeipa/ticket/6173 >> --- >> daemons/configure.ac | 12 ++++++++++++ >> daemons/ipa-kdb/ipa_kdb_mspac.c | 9 +++++++++ >> 2 files changed, 21 insertions(+) >> >> diff --git a/daemons/configure.ac b/daemons/configure.ac >> index >> 94d66d813728fe4e32f9e3c0eef920d8e2395d8f..5c5a1046397aa97ba18cafc1b81dc2a6fb2dfd34 >> 100644 >> --- a/daemons/configure.ac >> +++ b/daemons/configure.ac >> @@ -170,6 +170,18 @@ PKG_CHECK_MODULES([SAMBAUTIL], [samba-util]) >> SAMBA40EXTRA_LIBPATH="-L`$PKG_CONFIG --variable=libdir >> samba-util`/samba -Wl,-rpath=`$PKG_CONFIG --variable=libdir >> samba-util`/samba" >> AC_SUBST(SAMBA40EXTRA_LIBPATH) >> >> +bck_cflags="$CFLAGS" >> +CFLAGS="$NDRPAC_CFLAGS" >> +AC_CHECK_MEMBER( >> + [struct PAC_DOMAIN_GROUP_MEMBERSHIP.domain_sid], >> + [AC_DEFINE([HAVE_STRUCT_PAC_DOMAIN_GROUP_MEMBERSHIP], [1], >> + [struct PAC_DOMAIN_GROUP_MEMBERSHIP is available.])], >> + [AC_MSG_NOTICE([struct PAC_DOMAIN_GROUP_MEMBERSHIP is not >> available])], >> + [[#include >> + #include ]]) >> + >> +CFLAGS="$bck_cflags" >> + >> LIBPDB_NAME="" >> AC_CHECK_LIB([samba-passdb], >> [make_pdb_method], >> diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c >> b/daemons/ipa-kdb/ipa_kdb_mspac.c >> index >> 80e7055fd6cd7b962eeffbccc675a73d73700793..65cc03565dc06d1052c6acd0c0d6ee7265b37b36 >> 100644 >> --- a/daemons/ipa-kdb/ipa_kdb_mspac.c >> +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >> @@ -20,6 +20,8 @@ >> * along with this program. If not, see . >> */ >> >> +#include "config.h" >> + >> #include "ipa_kdb.h" >> #include "ipa_mspac.h" >> #include >> @@ -1533,10 +1535,17 @@ krb5_error_code >> filter_logon_info(krb5_context context, >> >> /* According to MS-KILE, ResourceGroups must be zero, so check >> * that it is the case here */ >> +#ifdef HAVE_STRUCT_PAC_DOMAIN_GROUP_MEMBERSHIP >> + if (info->info->resource_groups.domain_sid != NULL && >> + info->info->resource_groups.groups.count != 0) { >> + return EINVAL; >> + } >> +#else >> if (info->info->res_group_dom_sid != NULL && >> info->info->res_groups.count != 0) { >> return EINVAL; >> } >> +#endif >> >> return 0; >> } >> -- >> 2.9.2 >> > >>> From 7d064bc2dda88552f597c1e8dfa2cf176a89ac77 Mon Sep 17 00:00:00 2001 >> From: Lukas Slebodnik >> Date: Fri, 5 Aug 2016 08:34:23 +0200 >> Subject: [PATCH 2/2] ipa-kdb: Fix unit test after packaging changes >> in krb5 >> >> Resolves: >> https://fedorahosted.org/freeipa/ticket/6173 >> --- >> freeipa.spec.in | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/freeipa.spec.in b/freeipa.spec.in >> index >> 135e9c980011c6c2730c6c29a3c22098e48270d5..7b5bb906ea541da10e0a9f5f9970f5937728ee11 >> 100644 >> --- a/freeipa.spec.in >> +++ b/freeipa.spec.in >> @@ -108,6 +108,8 @@ BuildRequires: python-netifaces >= 0.10.4 >> # Build dependencies for unit tests >> BuildRequires: libcmocka-devel >> BuildRequires: nss_wrapper >> +# Required by ipa_kdb_tests >> +BuildRequires: %{_libdir}/krb5/plugins/kdb/db2.so >> >> %if 0%{?with_python3} >> BuildRequires: python3-devel >> -- >> 2.9.2 >> > >> -- >> Manage your subscription for the Freeipa-devel mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > > From flo at redhat.com Tue Aug 9 13:13:45 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 9 Aug 2016 15:13:45 +0200 Subject: [Freeipa-devel] [PATCH 0059] Fix to ipa-cacert-manage man and help differences In-Reply-To: References: <33e33813-1aeb-3d50-e05c-cadc3cb8e4bb@redhat.com> <182017ec-6015-c99a-8e96-cbeefaefa970@redhat.com> Message-ID: <5742111d-3713-8c46-4b12-281fc6e31b80@redhat.com> On 08/02/2016 09:11 AM, Stanislav Laznicka wrote: > On 07/19/2016 10:25 AM, Florence Blanc-Renaud wrote: >> On 07/15/2016 02:09 PM, Stanislav Laznicka wrote: >>> https://fedorahosted.org/freeipa/ticket/6013 >>> >>> >>> >> Hi Stanislav, >> >> thanks for your patch. As CERTFILE is added in the arguments for >> install, I would suggest to mention it in the command description. For >> instance: >> >> install >> - Install a CA certificate >> This command can be used to install the certificate contained in >> CERTFILE as a new CA certificate to IPA. >> >> Flo. >> > Hi, > > Thanks for the notice, I agree that it'd be better to be more verbose > about the CERTFILE argument. Please see the modified patch. > Hi, thanks for the updated patch. Looks good to me, ACK Flo. From slaznick at redhat.com Tue Aug 9 13:27:39 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 9 Aug 2016 15:27:39 +0200 Subject: [Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install In-Reply-To: References: <4975c47e-ce78-9e73-7849-f0d77909db7f@redhat.com> <2337c1e9-8d5a-8329-4e11-426b7f231839@redhat.com> <235931cd-67d6-6266-06cb-bd294395e1f3@redhat.com> <5af4f271-4add-ea82-2179-c9357fdac3d9@redhat.com> <1095646d-d146-3462-4158-11be0cc675f1@redhat.com> Message-ID: <5136b336-d64a-90a7-0e7f-a9a794abd6a6@redhat.com> On 08/04/2016 07:34 AM, Jan Cholasta wrote: > On 3.8.2016 19:39, Martin Basti wrote: >> >> >> On 03.08.2016 18:10, Petr Vobornik wrote: >>> On 07/13/2016 12:36 PM, Stanislav Laznicka wrote: >>>> On 07/13/2016 09:51 AM, Petr Vobornik wrote: >>>>> On 07/13/2016 08:26 AM, Stanislav Laznicka wrote: >>>>>> On 07/12/2016 08:44 AM, Stanislav Laznicka wrote: >>>>>>> On 07/11/2016 04:27 PM, Petr Vobornik wrote: >>>>>>>> On 07/11/2016 01:23 PM, Stanislav Laznicka wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/6046 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Isn't the bug about something else? >>>>>>>> >>>>>>>> The issue was that ipa-replica-install doesn't have --force-ntpd >>>>>>>> option. >>>>>>>> It is an option of ipa-client-install which is run from replica >>>>>>>> installer. >>>>>>>> >>>>>>>> The unattended mode is unrelated. >>>>>>> My understanding is that the bug says that '--force-ntpd' option >>>>>>> should not be shown when ipa-client-install is run during replica >>>>>>> installation. >>>>>>> >>>>>>> During replica installation, the ipa-client-install script is run >>>>>>> with >>>>>>> the '--unattended' flag in the 'ensure_enrolled()' function. >>>>>>> Being a >>>>>>> separate script, there's not many options on how to pass the >>>>>>> information not to show the message to ipa-client-install. Using >>>>>>> the >>>>>>> already used flag to get rid of the message seemed easiest to me. >>>>>>> Introducing a new 'hidden' flag (like '--from-replica'), on the >>>>>>> other >>>>>>> hand, seems a bit harsh. >>>>>>> >>>>>> Just to throw it out there - it's possible that the '--force-join' >>>>>> client option would also appear as a hint from the client install >>>>>> script >>>>>> (during replica installation). Should this also be muted somehow? >>>>>> To me, >>>>>> it seems reasonable to rather add it as an argument to >>>>>> ipa-replica-install to pass it to the client install script. >>>>>> >>>>> IMO client installation initiated from replica needs to have a >>>>> special >>>>> option(hidden in help) similar to --on-server (or what's its name). >>>>> E.g. >>>>> the name can be --replica-install. Maybe --on-server can be used >>>>> but it >>>>> may have other implication which might not be valid for this use >>>>> case. >>>>> >>>>> Anything else are just workarounds. Imagine that admin runs >>>>> ipa-client-install with --unattended or --force-join. He would >>>>> then not >>>>> get the message as now. >>> Reviving thread to get other opinion. >>> >>>> The --on-master option won't do here as it seems that the client would >>>> require some IPA pre-configuration for successful install. A new >>>> option >>>> will have to be created, then. >>> I'm for new "hidden" option. >> >> I'm against any hidden options, this should be made correctly by >> modularization/fixing of client install, to be able call it from python >> not as external process > > +1, but this is non-trivial and definitely not material for 4.4.1. For > 4.4.1 the hidden option should be OK. > >> >> Just from top of my head, can we just use option --no-ntp with client >> install in replica installer? Server NTP should not depend on client ntp >> config. >> I'm just afraid that we may get kerberos time issue during client >> install if client time does not match server time. >> >> Or second approach, always call client install from replica with >> --force-ntpd, unless there is --no-ntp used for replica, then call >> ipa-client-install with --no-ntp >> >> But it needs investigation. > > CCing David as he knows everything NTP-related. > >> >> Martin^2 >> >>> >>>> As I was trying to point out, the situation about --force-join is a >>>> bit >>>> different. The option again would be shown and is not available in >>>> ipa-replica-install. I think it should be available to allow direct >>>> replica installation even when previous installation failed/left some >>>> mess on the master (ofc the user could run `ipa-replica-manage del >>>> --cleanup` on the master instead). >>>> >>> That could work but imho is out of scope of this ticket. >> > > Please see the attached patch that always adds the --no-ntp option to ipa-client-install. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0057-2-Don-t-show-force-ntpd-option-in-replica-install.patch Type: text/x-patch Size: 1629 bytes Desc: not available URL: From lslebodn at redhat.com Tue Aug 9 13:53:36 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 9 Aug 2016 15:53:36 +0200 Subject: [Freeipa-devel] [PATCH] ipa-kdb: Allow to build with samba 4.5 In-Reply-To: <20160809115943.3teogq4gf2ltss36@redhat.com> References: <20160805070126.GA29546@10.4.128.1> <20160809115943.3teogq4gf2ltss36@redhat.com> Message-ID: <20160809135335.GG9181@10.4.128.1> On (09/08/16 14:59), Alexander Bokovoy wrote: >On Fri, 05 Aug 2016, Lukas Slebodnik wrote: >> ehlo, >> >> attached patches fix a build of freeipa on fedora 25 and fedora rawhide. >> IMHO, this change in krb5pac.h is an ABI change and samba guys should >> also bump a SONAME to related (private?) libraries. I could not see it; >> but maybe I overlooked it. >It an interesting question which you might raise upstream. krb5pac.h is >auto-generated from krb5pac.idl, the same happens for all IDL-based >definitions. They are not versioned, though. > I can ask but I am not sure which library is connected to the header file "gen_ndr/krb5pac.h". If it is a internal library then ABI change is not guaranted but ipa might have problems without requires. LS From slaznick at redhat.com Tue Aug 9 14:07:18 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 9 Aug 2016 16:07:18 +0200 Subject: [Freeipa-devel] [PATCH 0060] Add --force-join option to ipa-replica-install Message-ID: https://fedorahosted.org/freeipa/ticket/6183 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0060-Add-force-join-option-to-ipa-replica-install.patch Type: text/x-patch Size: 2385 bytes Desc: not available URL: From abokovoy at redhat.com Tue Aug 9 14:08:04 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 9 Aug 2016 17:08:04 +0300 Subject: [Freeipa-devel] [PATCH] ipa-kdb: Allow to build with samba 4.5 In-Reply-To: <20160809135335.GG9181@10.4.128.1> References: <20160805070126.GA29546@10.4.128.1> <20160809115943.3teogq4gf2ltss36@redhat.com> <20160809135335.GG9181@10.4.128.1> Message-ID: <20160809140804.nplazzd6ndxrf4hh@redhat.com> On Tue, 09 Aug 2016, Lukas Slebodnik wrote: >On (09/08/16 14:59), Alexander Bokovoy wrote: >>On Fri, 05 Aug 2016, Lukas Slebodnik wrote: >>> ehlo, >>> >>> attached patches fix a build of freeipa on fedora 25 and fedora rawhide. >>> IMHO, this change in krb5pac.h is an ABI change and samba guys should >>> also bump a SONAME to related (private?) libraries. I could not see it; >>> but maybe I overlooked it. >>It an interesting question which you might raise upstream. krb5pac.h is >>auto-generated from krb5pac.idl, the same happens for all IDL-based >>definitions. They are not versioned, though. >> >I can ask but I am not sure which library is connected to the >header file "gen_ndr/krb5pac.h". If it is a internal library then >ABI change is not guaranted but ipa might have problems without requires. We have dependency to libndr-krb5pac.so.0(NDR_KRB5PAC_0.0.1)(64bit) The problem here is that we could get some heads up with ABI tracker (http://abi-laboratory.pro/tracker/) but Samba is not there. I can ask Andrey P. about adding it, though. Fedora's Taskotron has dist.abicheck but any attempt to get results for Samba builds caused server error for me. -- / Alexander Bokovoy From mbasti at redhat.com Tue Aug 9 14:11:23 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 16:11:23 +0200 Subject: [Freeipa-devel] [PATCH 0059] Fix to ipa-cacert-manage man and help differences In-Reply-To: <5742111d-3713-8c46-4b12-281fc6e31b80@redhat.com> References: <33e33813-1aeb-3d50-e05c-cadc3cb8e4bb@redhat.com> <182017ec-6015-c99a-8e96-cbeefaefa970@redhat.com> <5742111d-3713-8c46-4b12-281fc6e31b80@redhat.com> Message-ID: <94e5054b-6dba-4484-fecf-369e423759c9@redhat.com> On 09.08.2016 15:13, Florence Blanc-Renaud wrote: > On 08/02/2016 09:11 AM, Stanislav Laznicka wrote: >> On 07/19/2016 10:25 AM, Florence Blanc-Renaud wrote: >>> On 07/15/2016 02:09 PM, Stanislav Laznicka wrote: >>>> https://fedorahosted.org/freeipa/ticket/6013 >>>> >>>> >>>> >>> Hi Stanislav, >>> >>> thanks for your patch. As CERTFILE is added in the arguments for >>> install, I would suggest to mention it in the command description. For >>> instance: >>> >>> install >>> - Install a CA certificate >>> This command can be used to install the certificate contained in >>> CERTFILE as a new CA certificate to IPA. >>> >>> Flo. >>> >> Hi, >> >> Thanks for the notice, I agree that it'd be better to be more verbose >> about the CERTFILE argument. Please see the modified patch. >> > > Hi, > > thanks for the updated patch. Looks good to me, > ACK > > Flo. > Pushed to master: bf6adfe69d2dc1e6cc76d17023f4049e49cfd8ae From pspacek at redhat.com Tue Aug 9 14:15:38 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 9 Aug 2016 16:15:38 +0200 Subject: [Freeipa-devel] [PATCH 686] Revert "spec: add conflict with bind-chroot to freeipa-server-dns" In-Reply-To: References: Message-ID: On 9.8.2016 14:16, Jan Cholasta wrote: > Hi, > > the attached patch fixes . ACK For historians: Further discussion can be found in https://bugzilla.redhat.com/show_bug.cgi?id=1309700. -- Petr^2 Spacek From tkrizek at redhat.com Tue Aug 9 14:16:24 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Tue, 9 Aug 2016 16:16:24 +0200 Subject: [Freeipa-devel] [PATCH 0002] Fix ipa-caacl-add-service error message Message-ID: <9c2f1919-c101-f867-41de-c45209e755e2@redhat.com> Hi, please review the attached patch. Thanks, Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tkrizek-0002-Fix-ipa-caacl-add-service-error-message.patch Type: text/x-patch Size: 961 bytes Desc: not available URL: From pspacek at redhat.com Tue Aug 9 14:18:42 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 9 Aug 2016 16:18:42 +0200 Subject: [Freeipa-devel] [PATCH 0002] Fix ipa-caacl-add-service error message In-Reply-To: <9c2f1919-c101-f867-41de-c45209e755e2@redhat.com> References: <9c2f1919-c101-f867-41de-c45209e755e2@redhat.com> Message-ID: <2d0e70ab-5624-ee74-1630-211111d7ddad@redhat.com> On 9.8.2016 16:16, Tomas Krizek wrote: > Hi, > > please review the attached patch. ACK -- Petr^2 Spacek From mbasti at redhat.com Tue Aug 9 14:18:43 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 16:18:43 +0200 Subject: [Freeipa-devel] [PATCH 0060] Add --force-join option to ipa-replica-install In-Reply-To: References: Message-ID: <84165298-500b-1638-f3b1-a6b20c8f9e63@redhat.com> On 09.08.2016 16:07, Stanislav Laznicka wrote: > https://fedorahosted.org/freeipa/ticket/6183 > > > Didn't we agreed that --force-join should be always used (without extra replica-install option) Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 9 14:21:31 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 16:21:31 +0200 Subject: [Freeipa-devel] [PATCH 686] Revert "spec: add conflict with bind-chroot to freeipa-server-dns" In-Reply-To: References: Message-ID: <3ea584be-4edb-427e-c2bb-039858a34099@redhat.com> On 09.08.2016 16:15, Petr Spacek wrote: > On 9.8.2016 14:16, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . > ACK > > For historians: Further discussion can be found in > https://bugzilla.redhat.com/show_bug.cgi?id=1309700. > Pushed to: master: 96db47cfa516911741dd7942509b0a94551dbace ipa-4-3: 56695d969325cb2cb754d0ea549c5b6face89c6f From mbasti at redhat.com Tue Aug 9 14:26:11 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 16:26:11 +0200 Subject: [Freeipa-devel] [PATCH 0002] Fix ipa-caacl-add-service error message In-Reply-To: <2d0e70ab-5624-ee74-1630-211111d7ddad@redhat.com> References: <9c2f1919-c101-f867-41de-c45209e755e2@redhat.com> <2d0e70ab-5624-ee74-1630-211111d7ddad@redhat.com> Message-ID: <30f9374a-9d55-ba37-909f-ae79c62a339c@redhat.com> On 09.08.2016 16:18, Petr Spacek wrote: > On 9.8.2016 16:16, Tomas Krizek wrote: >> Hi, >> >> please review the attached patch. > ACK > Pushed to master: af4ebaca6293779ef686c7bacffbc97945ebee95 From mbasti at redhat.com Tue Aug 9 14:28:58 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 16:28:58 +0200 Subject: [Freeipa-devel] [PATCH] 0100: Fix question marks in adders in topology graph In-Reply-To: References: Message-ID: <4f99f84d-9999-3267-0e3a-6e31ca92b2e5@redhat.com> On 08.08.2016 13:32, Pavel Vomacka wrote: > > > > On 08/05/2016 02:15 PM, Pavel Vomacka wrote: >> Hello, >> >> Please review attached patch. >> >> https://fedorahosted.org/freeipa/ticket/6175 >> >> >> > Changed commit message. > -- > Pavel^3 Vomacka > > ACK Pushed to master: 0fdbad1e1a146d7754e0f5377696a9341d50907b -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue Aug 9 14:47:16 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 10 Aug 2016 00:47:16 +1000 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <885c4c72-6e8a-4220-b25e-f577612368d2@redhat.com> References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> <885c4c72-6e8a-4220-b25e-f577612368d2@redhat.com> Message-ID: <20160809144716.GA23927@dhcp-40-8.bne.redhat.com> On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > On 8.8.2016 09:06, Fraser Tweedale wrote: > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > Hi, > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > Please review the attached patch with adds --certificate-out and > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > Note that --certificate-chain-out currently writes a bogus file due > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > 1) The client-side *-out options should be defined on the client side, not > > > on the server side. > > > > > Will option defined on client side be propagated to, and observable > > in the ipaserver plugin? The ipaserver plugin needs to observe that > > *-out has been requested and executes additional command(s) on that > > basis. > > Is there a reason not to *always* return the certs? > We hit Dogtag to retrieve them. > > > > > > > > 2) I don't think there should be additional information included in summary > > > (and it definitely should not be multi-line). I would rather inform the user > > > via an error message when unable to write the files. > > > > > I was just following the pattern of other commands that write certs, > > profile config, etc. Apart from consistency with other commands I > > agree that there is no need to have it. So I will remove it. > > > > > If you think there is an actual value in informing the user about > > > successfully writing the files, please use ipalib.messages for the job. > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 would be > > > concatenated PEM, as that's the most commonly used format in IPA (in > > > installers, there are no cert chains in API commands ATM). > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > or concatenated PEMs, but sometimes they must be concatenated > > forward, and othertimes backwards. There is no one size fits all. > > True, which is exactly why I think we should at least be self-consistent and > use concatenated PEM (and multi-value DER over the wire). > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept header). If we want list-of-PEMs between server and client we have to convert on the server. Do we have a good way of doing this without exec'ing `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' to do the conversion on the server? python-nss does not have PKCS7 functions and I am not keen on adding a pyasn1 PKCS7 parser just for the sake of pushing bits as list-of-PEMs. FWIW, man pages and code suggest that PKCS #7 is accepted in installer, etc. > > We can add an option to control the format later, but for now, > > Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst > > case is an admin has to invoke `openssl pkcs7' and concat the certs > > themselves. > > AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, > so I'm afraid the worst case would happen virtually always. > If you're OK with invoking OpenSSL on the client to convert PKCS #7 to list-of-PEMs (similar to what is done in ipapython.certdb.NSSDatabase) then we can have the client perform the conversion. > > > > > > > > 4) Over the wire, the certs should be DER-formatted, as that's the most > > > common wire format in other API commands. > > > > > OK. > > > > > > > > 5) What is the benefit in having the CA cert and the rest of the chain > > > separate? For end-entity certs it makes sense to separate the cert from the > > > CA chain, but for CA certs, you usually want the full chain, no? > > > > > If you want to anchor trust directly at a subca (e.g. restrict VPN > > login to certs issued by VPN sub-CA) then you often just want the > > cert. The chain option does subsume it, at cost of more work for > > administrators with this use case. I think it makes sense to keep > > both options. > > Does it? From what you described above, you either want just the sub-CA > cert, or the full chain including the sub-CA cert, in which case it might > make more sense to have a single --out option and a --chain flag. > How about --certificate-out which defaults to single cert, but does chain (as list-of-PEMs) when --chain flag given. Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more `--out' options. Thanks, Fraser From gkaihoro at redhat.com Tue Aug 9 14:55:37 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Tue, 9 Aug 2016 10:55:37 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts In-Reply-To: <1770070534.13853291.1470754325460.JavaMail.zimbra@redhat.com> Message-ID: <256010841.13930537.1470754537126.JavaMail.zimbra@redhat.com> Hello! Domain level 0 doesn't allow to create replica file on CA master, testcase was skipped with Domain level 0 https://fedorahosted.org/freeipa/ticket/6134 Best regards, Ganna Kaihorodova Associate Software Quality Engineer -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-gkaihoro-0003-Fix-for-integration-tests-replication-layouts.patch Type: text/x-patch Size: 1556 bytes Desc: not available URL: From lslebodn at redhat.com Tue Aug 9 16:17:58 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 9 Aug 2016 18:17:58 +0200 Subject: [Freeipa-devel] [PATCH] ipa-kdb: Allow to build with samba 4.5 In-Reply-To: <20160809140804.nplazzd6ndxrf4hh@redhat.com> References: <20160805070126.GA29546@10.4.128.1> <20160809115943.3teogq4gf2ltss36@redhat.com> <20160809135335.GG9181@10.4.128.1> <20160809140804.nplazzd6ndxrf4hh@redhat.com> Message-ID: <20160809161758.GI9181@10.4.128.1> On (09/08/16 17:08), Alexander Bokovoy wrote: >On Tue, 09 Aug 2016, Lukas Slebodnik wrote: >> On (09/08/16 14:59), Alexander Bokovoy wrote: >> > On Fri, 05 Aug 2016, Lukas Slebodnik wrote: >> > > ehlo, >> > > >> > > attached patches fix a build of freeipa on fedora 25 and fedora rawhide. >> > > IMHO, this change in krb5pac.h is an ABI change and samba guys should >> > > also bump a SONAME to related (private?) libraries. I could not see it; >> > > but maybe I overlooked it. >> > It an interesting question which you might raise upstream. krb5pac.h is >> > auto-generated from krb5pac.idl, the same happens for all IDL-based >> > definitions. They are not versioned, though. >> > >> I can ask but I am not sure which library is connected to the >> header file "gen_ndr/krb5pac.h". If it is a internal library then >> ABI change is not guaranted but ipa might have problems without requires. >We have dependency to libndr-krb5pac.so.0(NDR_KRB5PAC_0.0.1)(64bit) > >The problem here is that we could get some heads up with ABI tracker >(http://abi-laboratory.pro/tracker/) but Samba is not there. I can ask >Andrey P. about adding it, though. > >Fedora's Taskotron has dist.abicheck but any attempt to get results for >Samba builds caused server error for me. > I almost sent a mail to samba-devel about ABI change. But I realized that it's not an ABI change because the position of "struct dom_sid2 *" and "struct samr_RidWithAttributeArray" was not changed. They were just wrapped into "struct PAC_DOMAIN_GROUP_MEMBERSHIP" It was just an API change. LS From pspacek at redhat.com Tue Aug 9 16:27:41 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 9 Aug 2016 18:27:41 +0200 Subject: [Freeipa-devel] [PATCH 0561] backup: backup /etc/tmpfiles.d/dirsrv-instance-* In-Reply-To: References: Message-ID: <28280332-2bfd-6029-235a-4a236adcd23b@redhat.com> On 9.8.2016 12:37, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/6165 ACK -- Petr^2 Spacek From mbasti at redhat.com Tue Aug 9 16:31:25 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Aug 2016 18:31:25 +0200 Subject: [Freeipa-devel] [PATCH 0561] backup: backup /etc/tmpfiles.d/dirsrv-instance-* In-Reply-To: <28280332-2bfd-6029-235a-4a236adcd23b@redhat.com> References: <28280332-2bfd-6029-235a-4a236adcd23b@redhat.com> Message-ID: <2cecdc61-da9f-ffe2-7f31-c272b7e30262@redhat.com> On 09.08.2016 18:27, Petr Spacek wrote: > On 9.8.2016 12:37, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/6165 > ACK > Pushed to master: 148e021ac11793d77561fd7ffd3d11ecc09d86a5 From pvoborni at redhat.com Tue Aug 9 16:52:36 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 9 Aug 2016 18:52:36 +0200 Subject: [Freeipa-devel] [PATCH 0060] Add --force-join option to ipa-replica-install In-Reply-To: <84165298-500b-1638-f3b1-a6b20c8f9e63@redhat.com> References: <84165298-500b-1638-f3b1-a6b20c8f9e63@redhat.com> Message-ID: <44b90a51-6b3c-03fd-86e0-b3c65f626a2a@redhat.com> On 08/09/2016 04:18 PM, Martin Basti wrote: > > > On 09.08.2016 16:07, Stanislav Laznicka wrote: >> https://fedorahosted.org/freeipa/ticket/6183 >> >> >> > Didn't we agreed that --force-join should be always used (without extra > replica-install option) +1 > > Martin^2 > -- Petr Vobornik From blipton at redhat.com Tue Aug 9 18:22:00 2016 From: blipton at redhat.com (Ben Lipton) Date: Tue, 9 Aug 2016 14:22:00 -0400 Subject: [Freeipa-devel] [PATCH 0013-0015] Automatic CSR generation - usability improvements Message-ID: Hello, The attached patches improve upon my last patchset to: 0013: Add support for generating a full script that makes a CSR, rather than just a config, and use that support to automate the full flow from script generation through cert issuance Usage note: the UI for this could probably use work. I currently have the --helper-args param that allows additional data to be passed to the helper. Commonly this would be something like: Certutil: --helper-args '-d /path/to/nss/db' (precreated with certutil -N -d /path/to/nss/db) Openssl: --helper-args 'd /path/to/keyfile' (precreated with openssl genrsa -out /path/to/keyfile) See the commit message for a full command line. 0014: Allow the feature to be used by non-admin users 0015: Improve error handling by reporting a nice message if the mapping rules are broken, or if the data required to generate the subject DN is missing These improvements may make it easier to test the other patches. Thanks, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0013-Automate-full-cert-request-flow.patch Type: text/x-patch Size: 12093 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0014-Add-ACIs-for-mapping-rules.patch Type: text/x-patch Size: 10693 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0015-Improve-error-handling-for-certificate-mapping.patch Type: text/x-patch Size: 5505 bytes Desc: not available URL: From blipton at redhat.com Tue Aug 9 20:07:48 2016 From: blipton at redhat.com (Ben Lipton) Date: Tue, 9 Aug 2016 16:07:48 -0400 Subject: [Freeipa-devel] [PATCH 0013-0015] Automatic CSR generation - usability improvements In-Reply-To: References: Message-ID: <34577c09-7ad2-1658-d88c-ee572c5c7982@redhat.com> Aaand there's a typo in patch 15. Updated version attached. On 08/09/2016 02:22 PM, Ben Lipton wrote: > Hello, > > The attached patches improve upon my last patchset to: > > 0013: Add support for generating a full script that makes a CSR, > rather than just a config, and use that support to automate the full > flow from script generation through cert issuance > Usage note: the UI for this could probably use work. I currently have > the --helper-args param that allows additional data to be passed to > the helper. Commonly this would be something like: > Certutil: --helper-args '-d /path/to/nss/db' (precreated with certutil > -N -d /path/to/nss/db) > Openssl: --helper-args 'd /path/to/keyfile' (precreated with openssl > genrsa -out /path/to/keyfile) > See the commit message for a full command line. > > 0014: Allow the feature to be used by non-admin users > > 0015: Improve error handling by reporting a nice message if the > mapping rules are broken, or if the data required to generate the > subject DN is missing > > These improvements may make it easier to test the other patches. > > Thanks, > Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0015-2-Improve-error-handling-for-certificate-mapping.patch Type: text/x-patch Size: 5507 bytes Desc: not available URL: From jcholast at redhat.com Wed Aug 10 05:31:07 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Aug 2016 07:31:07 +0200 Subject: [Freeipa-devel] [PATCH 0060] Add --force-join option to ipa-replica-install In-Reply-To: <44b90a51-6b3c-03fd-86e0-b3c65f626a2a@redhat.com> References: <84165298-500b-1638-f3b1-a6b20c8f9e63@redhat.com> <44b90a51-6b3c-03fd-86e0-b3c65f626a2a@redhat.com> Message-ID: <378fc422-9620-2b38-cb64-316e4de99e5e@redhat.com> On 9.8.2016 18:52, Petr Vobornik wrote: > On 08/09/2016 04:18 PM, Martin Basti wrote: >> >> >> On 09.08.2016 16:07, Stanislav Laznicka wrote: >>> https://fedorahosted.org/freeipa/ticket/6183 >>> >>> >>> >> Didn't we agreed that --force-join should be always used (without extra >> replica-install option) > > +1 Did we? IMO the default behavior should be the same as in domain level 0 when trying to install replica on an already enrolled host. > >> >> Martin^2 >> -- Jan Cholasta From jcholast at redhat.com Wed Aug 10 05:39:43 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Aug 2016 07:39:43 +0200 Subject: [Freeipa-devel] [PATCH 0154] client: RPM require initscripts to get *-domainname.service In-Reply-To: <2493f706-b8c7-5848-a3a3-bc064e90f44a@redhat.com> References: <6b6bb9c3-9ac9-27c7-9e4c-3e637cab6744@redhat.com> <2493f706-b8c7-5848-a3a3-bc064e90f44a@redhat.com> Message-ID: On 8.8.2016 13:48, Petr Spacek wrote: > On 8.8.2016 13:37, Jan Cholasta wrote: >> Hi, >> >> On 8.8.2016 13:22, Petr Spacek wrote: >>> Hello, >>> >>> client: RPM require initscripts to get *-domainname.service >>> >>> https://fedorahosted.org/freeipa/ticket/4831 >> >> IIRC there was a task associated with the ticket to investigate if there is a >> better way of setting the domain name on boot. So... is there? >> >> AFAIK we set the domain name using authconfig, shouldn't authconfig be in >> charge of enabling any required services? > > As far as I can tell, this is the way to set NIS domain in RHEL/Fedora. > > authconfig cannot set NIS domain only, it does unwanted additional magic like > enabling rpcbind and ypbind services etc. > > Alternative is to drop sysctl file to /etc but I do not like it because it > would not be the Red Hat standard way of doing NIS domain config. > > Opinions? It looks like the current way of setting the domain name is correct, at least on Fedora/RHEL, so ACK. (Since it's platform-specific, we should move the code to ipaplatform, but that's another story.) Pushed to master: 771dea5c6bf1cca7b3756d2f1be48f613de14ceb -- Jan Cholasta From jcholast at redhat.com Wed Aug 10 05:55:21 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Aug 2016 07:55:21 +0200 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: <52e0d59b-71b0-72b4-a69e-4ce3e68d5289@redhat.com> References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> <57A0B845.5000105@redhat.com> <02645dd8-7a5d-9201-0a28-498de56dd9ab@redhat.com> <9001af3d-2831-6c3c-141d-941656bcbe94@redhat.com> <52e0d59b-71b0-72b4-a69e-4ce3e68d5289@redhat.com> Message-ID: On 9.8.2016 13:00, Martin Basti wrote: > > > On 05.08.2016 16:44, Martin Basti wrote: >> >> >> >> On 02.08.2016 18:08, Pavel Vomacka wrote: >>> >>> On 08/02/2016 05:31 PM, Pavel Vomacka wrote: >>>> >>>> >>>> On 08/02/2016 05:27 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 02.08.2016 17:12, Rob Crittenden wrote: >>>>>> Pavel Vomacka wrote: >>>>>>> Hello, >>>>>>> >>>>>>> please review attached patches which Split make lint to more >>>>>>> targets and >>>>>>> add jslint >>>>>> >>>>>> What's the driver to split the checks out into separate targets? >>>>> >>>>> It is called several times during build (makes build slower), and >>>>> you cannot run `make clean` in case you have wrong API.txt, because >>>>> it will explode >>>> Yes, definitely. >>> So I removed moving the aci and api checks and just add jslint. >>>>>> >>>>>> You are moving the makeapi and makeaci from version-update to >>>>>> lint. They were in version-update for a reason: downstream builds >>>>>> do not call lint. Downstream may patch code. API cannot break. >>>>> Can we update downstream spec then? >>>>> >>>>>> >>>>>> No ticket? >>>>> Pavel please file tickets. >>>>> >>>> Yes, I will file tickets for these changes. >>> Also ticket is now filed: >>> >>> https://fedorahosted.org/freeipa/ticket/6161 >>>>>> >>>>>> rob >>>>>> >>>>> Martin^2 >>>>> >>>> >>> >>> >>> >> >> ACK 0098-2: works for me >> >> Martin^2 >> >> > Pushed to master: 58da5fb4b9e81e872e0b59c17263071f8b2889da BuildRequires on jslint was not added to the spec file. Reopening the ticket. -- Jan Cholasta From slaznick at redhat.com Wed Aug 10 05:53:37 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 10 Aug 2016 07:53:37 +0200 Subject: [Freeipa-devel] [PATCH 0060] Add --force-join option to ipa-replica-install In-Reply-To: <378fc422-9620-2b38-cb64-316e4de99e5e@redhat.com> References: <84165298-500b-1638-f3b1-a6b20c8f9e63@redhat.com> <44b90a51-6b3c-03fd-86e0-b3c65f626a2a@redhat.com> <378fc422-9620-2b38-cb64-316e4de99e5e@redhat.com> Message-ID: <62dde92d-4978-ae47-abbc-354542ff44a2@redhat.com> On 08/10/2016 07:31 AM, Jan Cholasta wrote: > On 9.8.2016 18:52, Petr Vobornik wrote: >> On 08/09/2016 04:18 PM, Martin Basti wrote: >>> >>> >>> On 09.08.2016 16:07, Stanislav Laznicka wrote: >>>> https://fedorahosted.org/freeipa/ticket/6183 >>>> >>>> >>>> >>> Didn't we agreed that --force-join should be always used (without extra >>> replica-install option) >> >> +1 > > Did we? > > IMO the default behavior should be the same as in domain level 0 when > trying to install replica on an already enrolled host. That was my impression as well. From jcholast at redhat.com Wed Aug 10 06:21:22 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Aug 2016 08:21:22 +0200 Subject: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value In-Reply-To: <4646992f-30e3-a8e5-5d84-97bf3d054d75@redhat.com> References: <7b729ec0-619f-17d4-bf2f-dceca268a444@redhat.com> <5467c214-4555-0d07-520f-9a280da2f7c9@redhat.com> <31ceaafa-4f54-7bcb-e7d1-1452d3eb5f30@redhat.com> <809195d1-83f7-bf47-df6b-ad2cc1851e50@redhat.com> <4f559de0-9e98-72d7-8844-0ae1e9ce2863@redhat.com> <4646992f-30e3-a8e5-5d84-97bf3d054d75@redhat.com> Message-ID: On 1.8.2016 17:42, Petr Spacek wrote: > On 1.8.2016 08:27, Jan Cholasta wrote: >> On 28.7.2016 16:55, Petr Spacek wrote: >>> On 28.7.2016 16:44, Jan Cholasta wrote: >>>> On 28.7.2016 16:37, Petr Spacek wrote: >>>>> On 28.7.2016 16:35, Jan Cholasta wrote: >>>>>> On 28.7.2016 16:20, Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> install: Call hostnamectl set-hostname only if --hostname option is used >>>>>>> >>>>>>> This commit also splits hostname backup and configuration into two separate >>>>>>> functions. This allows us to backup hostname without setting it at the >>>>>>> same time. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/6071 >>>>>> >>>>>> Note that you can set ca_host in cfg unconditionally, the value is only >>>>>> valid >>>>>> during install and is not written anywhere. >>>>> >>>>> I prefer not to set it so the code blows up when we attempt to touch >>>>> variables >>>>> we should reference in particular setups. I.e. Take this as a first step >>>>> towards api.env without invalid values :-) >>>> >>>> OK. Use the proper condition then ("if setup_ca:"). >>> >>> Oh, I'm probably blind. Here is revised version. >> >> But you used "if not setup_ca:" rather than "if setup_ca:" :-) > > This patch set is cursed! The host name should not be backed up in server install if we are not changing it, so that it's not attempted to be changed on uninstall. Otherwise works for me. > > Petr^2 Spacek > >> >>> >>> Petr^2 Spacek >>> >>>> >>>>> >>>>> (In my stash I have a patch which removes nonsense defaults from >>>>> ipalib.constants. To be pushed when we a new git branch for 4.4...) >>>>> >>>>> Petr^2 Spacek >>>>> >>>>>>> server-install: Fix --hostname option to always override api.env values >>>>>>> >>>>>>> Attempts to compare local hostname with user-provided values are error >>>>>>> prone as we found out in #5794. This patch removes comparison and makes >>>>>>> the env values deterministic. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/6071 >>>>>>> >>>>>>> >>>>>>> Jan, this patch set should fix problems you have seen in containers. >> >> > > -- Jan Cholasta From pvomacka at redhat.com Wed Aug 10 06:34:26 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 10 Aug 2016 08:34:26 +0200 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> <57A0B845.5000105@redhat.com> <02645dd8-7a5d-9201-0a28-498de56dd9ab@redhat.com> <9001af3d-2831-6c3c-141d-941656bcbe94@redhat.com> <52e0d59b-71b0-72b4-a69e-4ce3e68d5289@redhat.com> Message-ID: On 08/10/2016 07:55 AM, Jan Cholasta wrote: > On 9.8.2016 13:00, Martin Basti wrote: >> >> >> On 05.08.2016 16:44, Martin Basti wrote: >>> >>> >>> >>> On 02.08.2016 18:08, Pavel Vomacka wrote: >>>> >>>> On 08/02/2016 05:31 PM, Pavel Vomacka wrote: >>>>> >>>>> >>>>> On 08/02/2016 05:27 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 02.08.2016 17:12, Rob Crittenden wrote: >>>>>>> Pavel Vomacka wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> please review attached patches which Split make lint to more >>>>>>>> targets and >>>>>>>> add jslint >>>>>>> >>>>>>> What's the driver to split the checks out into separate targets? >>>>>> >>>>>> It is called several times during build (makes build slower), and >>>>>> you cannot run `make clean` in case you have wrong API.txt, because >>>>>> it will explode >>>>> Yes, definitely. >>>> So I removed moving the aci and api checks and just add jslint. >>>>>>> >>>>>>> You are moving the makeapi and makeaci from version-update to >>>>>>> lint. They were in version-update for a reason: downstream builds >>>>>>> do not call lint. Downstream may patch code. API cannot break. >>>>>> Can we update downstream spec then? >>>>>> >>>>>>> >>>>>>> No ticket? >>>>>> Pavel please file tickets. >>>>>> >>>>> Yes, I will file tickets for these changes. >>>> Also ticket is now filed: >>>> >>>> https://fedorahosted.org/freeipa/ticket/6161 >>>>>>> >>>>>>> rob >>>>>>> >>>>>> Martin^2 >>>>>> >>>>> >>>> >>>> >>>> >>> >>> ACK 0098-2: works for me >>> >>> Martin^2 >>> >>> >> Pushed to master: 58da5fb4b9e81e872e0b59c17263071f8b2889da > > BuildRequires on jslint was not added to the spec file. Reopening the > ticket. > I think that it was. Here: https://www.redhat.com/archives/freeipa-devel/2016-August/msg00040.html several lines at the end of the patch add it. I'll close the ticket again. -- Pavel^3 Vomacka From jcholast at redhat.com Wed Aug 10 06:39:44 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Aug 2016 08:39:44 +0200 Subject: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint In-Reply-To: References: <3c90d1c4-08a4-62d1-f7a4-2f8e48779a4d@redhat.com> <57A0B845.5000105@redhat.com> <02645dd8-7a5d-9201-0a28-498de56dd9ab@redhat.com> <9001af3d-2831-6c3c-141d-941656bcbe94@redhat.com> <52e0d59b-71b0-72b4-a69e-4ce3e68d5289@redhat.com> Message-ID: On 10.8.2016 08:34, Pavel Vomacka wrote: > > > On 08/10/2016 07:55 AM, Jan Cholasta wrote: >> On 9.8.2016 13:00, Martin Basti wrote: >>> >>> >>> On 05.08.2016 16:44, Martin Basti wrote: >>>> >>>> >>>> >>>> On 02.08.2016 18:08, Pavel Vomacka wrote: >>>>> >>>>> On 08/02/2016 05:31 PM, Pavel Vomacka wrote: >>>>>> >>>>>> >>>>>> On 08/02/2016 05:27 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 02.08.2016 17:12, Rob Crittenden wrote: >>>>>>>> Pavel Vomacka wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> please review attached patches which Split make lint to more >>>>>>>>> targets and >>>>>>>>> add jslint >>>>>>>> >>>>>>>> What's the driver to split the checks out into separate targets? >>>>>>> >>>>>>> It is called several times during build (makes build slower), and >>>>>>> you cannot run `make clean` in case you have wrong API.txt, because >>>>>>> it will explode >>>>>> Yes, definitely. >>>>> So I removed moving the aci and api checks and just add jslint. >>>>>>>> >>>>>>>> You are moving the makeapi and makeaci from version-update to >>>>>>>> lint. They were in version-update for a reason: downstream builds >>>>>>>> do not call lint. Downstream may patch code. API cannot break. >>>>>>> Can we update downstream spec then? >>>>>>> >>>>>>>> >>>>>>>> No ticket? >>>>>>> Pavel please file tickets. >>>>>>> >>>>>> Yes, I will file tickets for these changes. >>>>> Also ticket is now filed: >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6161 >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> ACK 0098-2: works for me >>>> >>>> Martin^2 >>>> >>>> >>> Pushed to master: 58da5fb4b9e81e872e0b59c17263071f8b2889da >> >> BuildRequires on jslint was not added to the spec file. Reopening the >> ticket. >> > I think that it was. Here: > https://www.redhat.com/archives/freeipa-devel/2016-August/msg00040.html > several lines at the end of the patch add it. I'll close the ticket again. Oops, my bad. Please do. -- Jan Cholasta From tbordaz at redhat.com Wed Aug 10 06:37:45 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 10 Aug 2016 08:37:45 +0200 Subject: [Freeipa-devel] [PATCH] 0024 memory leak in ipapwd plugin Message-ID: <57AACBB9.1050608@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-44-tbordaz-024-ipa-pwd-extop-memory-leak-during-passord-update.patch Type: text/x-patch Size: 1807 bytes Desc: not available URL: From tbordaz at redhat.com Wed Aug 10 06:46:49 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 10 Aug 2016 08:46:49 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <20160809113803.2jehpfuxnrg4wozr@redhat.com> References: <20160808083518.x2ose47ttuotcdsy@redhat.com> <20160808085100.GD7069@10.4.128.1> <20160808085623.daozgyxrlltzviuu@redhat.com> <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> <20160808152007.v5fq23paiaa55khf@redhat.com> <57A8A57E.3070003@redhat.com> <57A9BD64.5050308@redhat.com> <20160809113803.2jehpfuxnrg4wozr@redhat.com> Message-ID: <57AACDD9.7070102@redhat.com> On 08/09/2016 01:38 PM, Alexander Bokovoy wrote: > On Tue, 09 Aug 2016, thierry bordaz wrote: >> >> >> On 08/09/2016 12:49 PM, Martin Basti wrote: >>> >>> >>> On 08.08.2016 17:30, thierry bordaz wrote: >>>> >>>> >>>> On 08/08/2016 05:20 PM, Alexander Bokovoy wrote: >>>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>> >>>>>> >>>>>> On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>>>>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>>>>>> On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>>>>>> On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>>>>>> On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>>>>>> When SSSD resolves AD users on behalf of slapi-nis, it can >>>>>>>>>>>> accept any >>>>>>>>>>>>> user identifier, including user principal name (UPN) which >>>>>>>>>>>>> may be >>>>>>>>>>>>> different than the canonical user name which SSSD returns. >>>>>>>>>>>>> >>>>>>>>>>>>> As result, the entry created by slapi-nis will be using >>>>>>>>>>>> canonical user >>>>>>>>>>>>> name but the filter for search will refer to the original >>>>>>>>>>>>> (aliased) >>>>>>>>>>>>> name. The search will not match the newly created entry. >>>>>>>>>>>>> >>>>>>>>>>>>> The issue is fixed in slapi-nis-0.56.1 by returning two >>>>>>>>>>>>> values for >>>>>>>>>>>>> 'uid' attribute: the canonical one and the aliased one. >>>>>>>>>>>>> This way the >>>>>>>>>>>>> search will match. >>>>>>>>>>>>> >>>>>>>>>>>>> Standard LDAP schema allows multiple values for 'uid' >>>>>>>>>>>>> attribute. We >>>>>>>>>>>>> actually use the same trick for 'cn' attribute in the >>>>>>>>>>>>> groups map >>>>>>>>>>>>> already. >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>>>>>>>>>> No, this is not required. In Fedora we'll submit a combined >>>>>>>>>>> update -- >>>>>>>>>>> I've built slapi-nis-0.56.1-1 packages for f24, f25, and >>>>>>>>>>> rawhide already >>>>>>>>>>> but did not submit a Bodhi request. >>>>>>>>>>> >>>>>>>>>> How is combined updated related to requires to slapi-nis-0.56.1? >>>>>>>>>> It will not prevent tu update freeipa without new slapi-nis. >>>>>>>>>> >>>>>>>>>> e.g. >>>>>>>>>> dnf update freeipa-server. >>>>>>>>> An update file in FreeIPA that is proposed by this patch does >>>>>>>>> not affect >>>>>>>>> operation of the older slapi-nis deployment once update is >>>>>>>>> applied. >>>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Is '%first' returning the first value of the attribute 'uid' ? >>>>>>>> If there are several values (canonical, alias,... ), does the >>>>>>>> order matters ? >>>>>>> We insert the canonical one first and it seems that 389-ds does not >>>>>>> change the order, at least in my tests. You can see the output >>>>>>> in the >>>>>>> bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 >>>>>> >>>>>> From ldap pov (https://tools.ietf.org/html/rfc4511#section-4.1.7) >>>>>> the order of the values is not preserved. >>>>>> I think it is a bit risky to rely on a specific order especially >>>>>> with complex updates (adding several values in a single mod, >>>>>> replace) and replication. >>>>>> would it help to add canonical value with a subtype (e.g. >>>>>> 'uid;canonical: ') ? >>>>> Not sure how what you are mention is relevant here. We talk about >>>>> slapi-nis map cache entries which are not modified, replaced or >>>>> replicated anywhere by anything other than slapi-nis itself. When >>>>> entries are changed by slapi-nis, they are regenerated from scratch. >>>>> >>>>> Your worries do not apply here. >>>> ok. >>>> I understand my mistake, I was thinking the compat entry had a >>>> associated real entry in ldap and this real entry had two uid values. >>>> >>> >>> So, could you provide ack thierry? >>> >>> Martin >> >> Sure but I would have to test first :-) >> >> Alexander, how can I test this ? > slapi-nis 0.56.1-1 packages are available in koji for f24-f26: > http://koji.fedoraproject.org/koji/packageinfo?packageID=6609 Thanks Alexander. So to test this change is there an other way (simpler) than setting up AD/trust ? From dkupka at redhat.com Wed Aug 10 06:52:55 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 10 Aug 2016 08:52:55 +0200 Subject: [Freeipa-devel] [PATCH 685] parameters: move the `confirm` kwarg to Param In-Reply-To: <71af5d7f-a48d-39e0-0b27-90835126fdb8@redhat.com> References: <71af5d7f-a48d-39e0-0b27-90835126fdb8@redhat.com> Message-ID: <95e9cf3a-e8f8-11a4-2b79-37c83b8959dd@redhat.com> On 08/08/16 13:40, Jan Cholasta wrote: > On 8.8.2016 13:26, Martin Basti wrote: >> >> >> On 08.08.2016 13:27, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >>> >>> >>> >> Please document this change in Param dosctring >> >> --- a/ipalib/parameters.py >> +++ b/ipalib/parameters.py >> @@ -418,6 +418,7 @@ class Param(ReadOnly): >> ('cli_metavar', str, None), >> ('no_convert', bool, False), >> ('deprecated', bool, False), >> + ('confirm', bool, True), >> >> >> Martin^2 >> >> > > > > Works for me, ACK. Pushed to master: e9c1d21b9fec17ab13894885eb1238631ecc43e5 -- David Kupka From abokovoy at redhat.com Wed Aug 10 07:03:37 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Aug 2016 10:03:37 +0300 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <57AACDD9.7070102@redhat.com> References: <20160808085623.daozgyxrlltzviuu@redhat.com> <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> <20160808152007.v5fq23paiaa55khf@redhat.com> <57A8A57E.3070003@redhat.com> <57A9BD64.5050308@redhat.com> <20160809113803.2jehpfuxnrg4wozr@redhat.com> <57AACDD9.7070102@redhat.com> Message-ID: <20160810070337.kt4auntwnvznvplb@redhat.com> On Wed, 10 Aug 2016, thierry bordaz wrote: > > >On 08/09/2016 01:38 PM, Alexander Bokovoy wrote: >>On Tue, 09 Aug 2016, thierry bordaz wrote: >>> >>> >>>On 08/09/2016 12:49 PM, Martin Basti wrote: >>>> >>>> >>>>On 08.08.2016 17:30, thierry bordaz wrote: >>>>> >>>>> >>>>>On 08/08/2016 05:20 PM, Alexander Bokovoy wrote: >>>>>>On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>> >>>>>>> >>>>>>>On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>>>>>>>On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>>>>>>>On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>>>>>>>On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>>>>>>>On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>>>>>>>When SSSD resolves AD users on behalf of slapi-nis, it can >>>>>>>>>>>>>accept any >>>>>>>>>>>>>>user identifier, including user principal >>>>>>>>>>>>>>name (UPN) which may be >>>>>>>>>>>>>>different than the canonical user name which SSSD returns. >>>>>>>>>>>>>> >>>>>>>>>>>>>>As result, the entry created by slapi-nis will be using >>>>>>>>>>>>>canonical user >>>>>>>>>>>>>>name but the filter for search will refer to >>>>>>>>>>>>>>the original (aliased) >>>>>>>>>>>>>>name. The search will not match the newly created entry. >>>>>>>>>>>>>> >>>>>>>>>>>>>>The issue is fixed in slapi-nis-0.56.1 by >>>>>>>>>>>>>>returning two values for >>>>>>>>>>>>>>'uid' attribute: the canonical one and the >>>>>>>>>>>>>>aliased one. This way the >>>>>>>>>>>>>>search will match. >>>>>>>>>>>>>> >>>>>>>>>>>>>>Standard LDAP schema allows multiple values >>>>>>>>>>>>>>for 'uid' attribute. We >>>>>>>>>>>>>>actually use the same trick for 'cn' >>>>>>>>>>>>>>attribute in the groups map >>>>>>>>>>>>>>already. >>>>>>>>>>>>>> >>>>>>>>>>>>>>https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>Hello, >>>>>>>>>>>>> >>>>>>>>>>>>>should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>>>>>>>>>>>No, this is not required. In Fedora we'll submit >>>>>>>>>>>>a combined update -- >>>>>>>>>>>>I've built slapi-nis-0.56.1-1 packages for f24, >>>>>>>>>>>>f25, and rawhide already >>>>>>>>>>>>but did not submit a Bodhi request. >>>>>>>>>>>> >>>>>>>>>>>How is combined updated related to requires to slapi-nis-0.56.1? >>>>>>>>>>>It will not prevent tu update freeipa without new slapi-nis. >>>>>>>>>>> >>>>>>>>>>>e.g. >>>>>>>>>>>dnf update freeipa-server. >>>>>>>>>>An update file in FreeIPA that is proposed by this >>>>>>>>>>patch does not affect >>>>>>>>>>operation of the older slapi-nis deployment once >>>>>>>>>>update is applied. >>>>>>>>>> >>>>>>>>> >>>>>>>>>Hi, >>>>>>>>> >>>>>>>>>Is '%first' returning the first value of the attribute 'uid' ? >>>>>>>>>If there are several values (canonical, alias,... ), >>>>>>>>>does the order matters ? >>>>>>>>We insert the canonical one first and it seems that 389-ds does not >>>>>>>>change the order, at least in my tests. You can see the >>>>>>>>output in the >>>>>>>>bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 >>>>>>> >>>>>>>From ldap pov >>>>>>>(https://tools.ietf.org/html/rfc4511#section-4.1.7) the >>>>>>>order of the values is not preserved. >>>>>>>I think it is a bit risky to rely on a specific order >>>>>>>especially with complex updates (adding several values in >>>>>>>a single mod, replace) and replication. >>>>>>>would it help to add canonical value with a subtype (e.g. >>>>>>>'uid;canonical: ') ? >>>>>>Not sure how what you are mention is relevant here. We talk about >>>>>>slapi-nis map cache entries which are not modified, replaced or >>>>>>replicated anywhere by anything other than slapi-nis itself. When >>>>>>entries are changed by slapi-nis, they are regenerated from scratch. >>>>>> >>>>>>Your worries do not apply here. >>>>>ok. >>>>>I understand my mistake, I was thinking the compat entry had a >>>>>associated real entry in ldap and this real entry had two uid >>>>>values. >>>>> >>>> >>>>So, could you provide ack thierry? >>>> >>>>Martin >>> >>>Sure but I would have to test first :-) >>> >>>Alexander, how can I test this ? >>slapi-nis 0.56.1-1 packages are available in koji for f24-f26: >>http://koji.fedoraproject.org/koji/packageinfo?packageID=6609 > >Thanks Alexander. So to test this change is there an other way >(simpler) than setting up AD/trust ? I don't think so. We don't have UPNs in FreeIPA on the level of identity lookups and we don't allow to lookup identity by email, so you are left with using a proper AD trust and UPN suffixes in AD forest. -- / Alexander Bokovoy From jcholast at redhat.com Wed Aug 10 07:30:07 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Aug 2016 09:30:07 +0200 Subject: [Freeipa-devel] [PATCH 687] client: add missing output params to client-side commands Message-ID: <6ca37d48-4221-b007-9462-ef1d5d9655e6@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-687-client-add-missing-output-params-to-client-side-comm.patch Type: text/x-patch Size: 3318 bytes Desc: not available URL: From abokovoy at redhat.com Wed Aug 10 07:28:00 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Aug 2016 10:28:00 +0300 Subject: [Freeipa-devel] [PATCH 687] client: add missing output params to client-side commands In-Reply-To: <6ca37d48-4221-b007-9462-ef1d5d9655e6@redhat.com> References: <6ca37d48-4221-b007-9462-ef1d5d9655e6@redhat.com> Message-ID: <20160810072800.viogo74cicqhvcbd@redhat.com> On Wed, 10 Aug 2016, Jan Cholasta wrote: >Hi, > >the attached patch fixes . > >Honza > >-- >Jan Cholasta >From 2f21d1eee2ea2e3cc568b75bd32f24d7188cbe59 Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Wed, 10 Aug 2016 09:02:47 +0200 >Subject: [PATCH] client: add missing output params to client-side commands > >Add output params for the otptoken-add-yubikey, vault-add, vault-mod, >vault-archive and vault-retrieve commands. > >This fixes the commands not having any output in CLI. > >https://fedorahosted.org/freeipa/ticket/6182 >--- > ipaclient/plugins/otptoken_yubikey.py | 6 ++++++ > ipaclient/plugins/vault.py | 24 ++++++++++++++++++++++++ > 2 files changed, 30 insertions(+) > >diff --git a/ipaclient/plugins/otptoken_yubikey.py b/ipaclient/plugins/otptoken_yubikey.py >index bfa244c..549376a 100644 >--- a/ipaclient/plugins/otptoken_yubikey.py >+++ b/ipaclient/plugins/otptoken_yubikey.py >@@ -106,6 +106,12 @@ class otptoken_add_yubikey(Command): > for option in super(otptoken_add_yubikey, self).get_options(): > yield option > >+ def get_output_params(self): >+ for param in self.api.Command.otptoken_add.output_params(): >+ yield param >+ for param in super(otptoken_add_yubikey, self).get_output_params(): >+ yield param >+ > def _iter_output(self): > return self.api.Command.otptoken_add.output() > >diff --git a/ipaclient/plugins/vault.py b/ipaclient/plugins/vault.py >index 1e715fd..c0ded21 100644 >--- a/ipaclient/plugins/vault.py >+++ b/ipaclient/plugins/vault.py >@@ -223,6 +223,12 @@ class vault_add(Local): > for option in super(vault_add, self).get_options(): > yield option > >+ def get_output_params(self): >+ for param in self.api.Command.vault_add_internal.output_params(): >+ yield param >+ for param in super(vault_add, self).get_output_params(): >+ yield param >+ > def _iter_output(self): > return self.api.Command.vault_add_internal.output() > >@@ -423,6 +429,12 @@ class vault_mod(Local): > for option in super(vault_mod, self).get_options(): > yield option > >+ def get_output_params(self): >+ for param in self.api.Command.vault_mod_internal.output_params(): >+ yield param >+ for param in super(vault_mod, self).get_output_params(): >+ yield param >+ > def _iter_output(self): > return self.api.Command.vault_mod_internal.output() > >@@ -607,6 +619,12 @@ class vault_archive(Local): > for option in super(vault_archive, self).get_options(): > yield option > >+ def get_output_params(self): >+ for param in self.api.Command.vault_archive_internal.output_params(): >+ yield param >+ for param in super(vault_archive, self).get_output_params(): >+ yield param >+ > def _iter_output(self): > return self.api.Command.vault_archive_internal.output() > >@@ -855,6 +873,12 @@ class vault_retrieve(Local): > for option in super(vault_retrieve, self).get_options(): > yield option > >+ def get_output_params(self): >+ for param in self.api.Command.vault_retrieve_internal.output_params(): >+ yield param >+ for param in super(vault_retrieve, self).get_output_params(): >+ yield param >+ > def _iter_output(self): > return self.api.Command.vault_retrieve_internal.output() > ACK. -- / Alexander Bokovoy From pspacek at redhat.com Wed Aug 10 08:09:35 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 10 Aug 2016 10:09:35 +0200 Subject: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value In-Reply-To: References: <7b729ec0-619f-17d4-bf2f-dceca268a444@redhat.com> <5467c214-4555-0d07-520f-9a280da2f7c9@redhat.com> <31ceaafa-4f54-7bcb-e7d1-1452d3eb5f30@redhat.com> <809195d1-83f7-bf47-df6b-ad2cc1851e50@redhat.com> <4f559de0-9e98-72d7-8844-0ae1e9ce2863@redhat.com> <4646992f-30e3-a8e5-5d84-97bf3d054d75@redhat.com> Message-ID: <48309a4a-5b5b-cae0-485e-8f246ff10cba@redhat.com> On 10.8.2016 08:21, Jan Cholasta wrote: > On 1.8.2016 17:42, Petr Spacek wrote: >> On 1.8.2016 08:27, Jan Cholasta wrote: >>> On 28.7.2016 16:55, Petr Spacek wrote: >>>> On 28.7.2016 16:44, Jan Cholasta wrote: >>>>> On 28.7.2016 16:37, Petr Spacek wrote: >>>>>> On 28.7.2016 16:35, Jan Cholasta wrote: >>>>>>> On 28.7.2016 16:20, Petr Spacek wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> install: Call hostnamectl set-hostname only if --hostname option is used >>>>>>>> >>>>>>>> This commit also splits hostname backup and configuration into two >>>>>>>> separate >>>>>>>> functions. This allows us to backup hostname without setting it at the >>>>>>>> same time. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/6071 >>>>>>> >>>>>>> Note that you can set ca_host in cfg unconditionally, the value is only >>>>>>> valid >>>>>>> during install and is not written anywhere. >>>>>> >>>>>> I prefer not to set it so the code blows up when we attempt to touch >>>>>> variables >>>>>> we should reference in particular setups. I.e. Take this as a first step >>>>>> towards api.env without invalid values :-) >>>>> >>>>> OK. Use the proper condition then ("if setup_ca:"). >>>> >>>> Oh, I'm probably blind. Here is revised version. >>> >>> But you used "if not setup_ca:" rather than "if setup_ca:" :-) >> >> This patch set is cursed! > > The host name should not be backed up in server install if we are not changing > it, so that it's not attempted to be changed on uninstall. > > Otherwise works for me. Okay, now I see that ipa-backup/restore is storing the host name in backup header so we do not need it in sysrestore. New patches are attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0151-4-server-install-Fix-hostname-option-to-always-overrid.patch Type: text/x-patch Size: 1838 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0152-4-install-Call-hostnamectl-set-hostname-only-if-hostna.patch Type: text/x-patch Size: 6035 bytes Desc: not available URL: From pspacek at redhat.com Wed Aug 10 08:15:02 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 10 Aug 2016 10:15:02 +0200 Subject: [Freeipa-devel] [PATCH 0013-0015] Automatic CSR generation - usability improvements In-Reply-To: <34577c09-7ad2-1658-d88c-ee572c5c7982@redhat.com> References: <34577c09-7ad2-1658-d88c-ee572c5c7982@redhat.com> Message-ID: <830d6a06-36c8-72c3-e780-9753f2a1bc80@redhat.com> On 9.8.2016 22:07, Ben Lipton wrote: > Aaand there's a typo in patch 15. Updated version attached. Ben, it would be great if you can always send whole patch set, including the patches which were not changed from the previous iteration. It is getting quite hard to follow and mix-and-match patches from e-mails into one patch set. As a nice to have addition, you can push the whole patch set to Github (or somewhere else) so we can just clone the repo and be done with it :-) Thank you for understanding. Petr^2 Spacek > > On 08/09/2016 02:22 PM, Ben Lipton wrote: >> Hello, >> >> The attached patches improve upon my last patchset to: >> >> 0013: Add support for generating a full script that makes a CSR, rather than >> just a config, and use that support to automate the full flow from script >> generation through cert issuance >> Usage note: the UI for this could probably use work. I currently have the >> --helper-args param that allows additional data to be passed to the helper. >> Commonly this would be something like: >> Certutil: --helper-args '-d /path/to/nss/db' (precreated with certutil -N -d >> /path/to/nss/db) >> Openssl: --helper-args 'd /path/to/keyfile' (precreated with openssl genrsa >> -out /path/to/keyfile) >> See the commit message for a full command line. >> >> 0014: Allow the feature to be used by non-admin users >> >> 0015: Improve error handling by reporting a nice message if the mapping >> rules are broken, or if the data required to generate the subject DN is missing >> >> These improvements may make it easier to test the other patches. >> >> Thanks, >> Ben >> >> > > > > -- Petr^2 Spacek From tdudlak at redhat.com Wed Aug 10 08:17:12 2016 From: tdudlak at redhat.com (Tibor Dudlak) Date: Wed, 10 Aug 2016 10:17:12 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Added support for authentication with user certificate Message-ID: Hi, I have improved my previous patch for authentication with user certificate/smartcard. This patch includes patches and plugin and apache configuration described here: http://www.freeipa.org/page/V4/External_Authentication/Setup It also contains steps to configure and test this feature. Once this patch is merged and released I will simplify this page to not confuse customers. On Fri, Aug 5, 2016 at 3:58 PM, Petr Vobornik wrote: > On 08/05/2016 02:57 PM, Tibor Dudlak wrote: > >... > > Let's assume that we will go with this approach and not separate RPM. > > 1. ipa.conf version needs to be bumped > We have found another problem with ipa.conf approach so I have moved configuration of apache for plugin from ipa.conf into completely separated file to be not configured in FreeIPA by default. As you said it may cause some security issues and it definitely causes errors when plugin dependences are not installed nor configured. 2. Do not put the web ui plugin in src/freeipa/plugins dir. That is a > dir for core UI plugins. This one is sort of hybrid - basically a third > party plugin added to core package but enabled as third party because > the feature is experimental. > > Create rather a new dir for that. E.g. plugins.d as Alexander suggested > -> freeipa/install/ui/src/plugins.d/cert_auth/cert_auth.js > > 3. unrelated and "alternative solution" comments needs to be removed > from the UI plugin. They were added to the example plugin > https://pvoborni.fedorapeople.org/plugins/loginauth/loginauth.js mostly > to help you with the development. > > 4. Add comment to freeipa.spec.in describing what the plugin is and why > it is put there this way. > > 5. The plugin itself deserves better description as well. Right now > there is the general description. > > 6. I have not tried it, but make sure that it passes jslint (`jsl -conf > jsl.conf`) Easiest may be to use temp(i.e. do not include it here) > jsl.conf e.g.: https://pvoborni.fedorapeople. > org/plugins/loginauth/jsl.conf > > -- > Petr Vobornik > I hope result of jsl http://pastebin.test.redhat.com/400076 means that things passed. Thanks Petr for review and I hope this patch will cover all concerns he had. Addressing ticket: https://fedorahosted.org/freeipa/ticket/5764 Thank you. -- Tibor Dudl?k Intern - Identity management Special Projects Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tdudlak-0003-Added-support-for-authentication-with-user-certificate.patch Type: text/x-patch Size: 10301 bytes Desc: not available URL: From dkupka at redhat.com Wed Aug 10 08:27:24 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 10 Aug 2016 10:27:24 +0200 Subject: [Freeipa-devel] [PATCH 687] client: add missing output params to client-side commands In-Reply-To: <6ca37d48-4221-b007-9462-ef1d5d9655e6@redhat.com> References: <6ca37d48-4221-b007-9462-ef1d5d9655e6@redhat.com> Message-ID: <6b8c4174-c4ca-5910-7d4d-3bdcda43cbc2@redhat.com> On 10/08/16 09:30, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > Works for me, ACK. Pushed to master: 20ee4a73e7b9e0ccdc7725ff4b87404d5543992e -- David Kupka From ofayans at redhat.com Wed Aug 10 08:38:02 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 10 Aug 2016 10:38:02 +0200 Subject: [Freeipa-devel] [test][patch-0057] test for ticket N 6146 Message-ID: <57AAE7EA.5090604@redhat.com> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0057-Test-for-installing-rules-with-service-principals.patch Type: text/x-patch Size: 4093 bytes Desc: not available URL: From jcholast at redhat.com Wed Aug 10 08:48:22 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Aug 2016 10:48:22 +0200 Subject: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value In-Reply-To: <48309a4a-5b5b-cae0-485e-8f246ff10cba@redhat.com> References: <7b729ec0-619f-17d4-bf2f-dceca268a444@redhat.com> <5467c214-4555-0d07-520f-9a280da2f7c9@redhat.com> <31ceaafa-4f54-7bcb-e7d1-1452d3eb5f30@redhat.com> <809195d1-83f7-bf47-df6b-ad2cc1851e50@redhat.com> <4f559de0-9e98-72d7-8844-0ae1e9ce2863@redhat.com> <4646992f-30e3-a8e5-5d84-97bf3d054d75@redhat.com> <48309a4a-5b5b-cae0-485e-8f246ff10cba@redhat.com> Message-ID: <2e35e206-0c66-5f7c-8647-46a8c9abf4fd@redhat.com> On 10.8.2016 10:09, Petr Spacek wrote: > On 10.8.2016 08:21, Jan Cholasta wrote: >> On 1.8.2016 17:42, Petr Spacek wrote: >>> On 1.8.2016 08:27, Jan Cholasta wrote: >>>> On 28.7.2016 16:55, Petr Spacek wrote: >>>>> On 28.7.2016 16:44, Jan Cholasta wrote: >>>>>> On 28.7.2016 16:37, Petr Spacek wrote: >>>>>>> On 28.7.2016 16:35, Jan Cholasta wrote: >>>>>>>> On 28.7.2016 16:20, Petr Spacek wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> install: Call hostnamectl set-hostname only if --hostname option is used >>>>>>>>> >>>>>>>>> This commit also splits hostname backup and configuration into two >>>>>>>>> separate >>>>>>>>> functions. This allows us to backup hostname without setting it at the >>>>>>>>> same time. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/6071 >>>>>>>> >>>>>>>> Note that you can set ca_host in cfg unconditionally, the value is only >>>>>>>> valid >>>>>>>> during install and is not written anywhere. >>>>>>> >>>>>>> I prefer not to set it so the code blows up when we attempt to touch >>>>>>> variables >>>>>>> we should reference in particular setups. I.e. Take this as a first step >>>>>>> towards api.env without invalid values :-) >>>>>> >>>>>> OK. Use the proper condition then ("if setup_ca:"). >>>>> >>>>> Oh, I'm probably blind. Here is revised version. >>>> >>>> But you used "if not setup_ca:" rather than "if setup_ca:" :-) >>> >>> This patch set is cursed! >> >> The host name should not be backed up in server install if we are not changing >> it, so that it's not attempted to be changed on uninstall. >> >> Otherwise works for me. > > Okay, now I see that ipa-backup/restore is storing the host name in backup > header so we do not need it in sysrestore. > > New patches are attached. Thanks, ACK. Pushed to master: 80e544e7a98ff22469e9d3a4f7bda2ed234601aa -- Jan Cholasta From slaznick at redhat.com Wed Aug 10 09:02:04 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 10 Aug 2016 11:02:04 +0200 Subject: [Freeipa-devel] [PATCH 0061] Removing objectclass expectation for LDAP*ReverseMember based commands Message-ID: <4e98844c-410f-7cb8-edfc-30cdc73b6971@redhat.com> Hello, I missed some tests in patch to https://fedorahosted.org/freeipa/ticket/5892. This patch should fix the rest of the additional objectclass expectations mentioned in https://fedorahosted.org/freeipa/ticket/6198. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0061-Removed-objectclass-from-LDAP-ReverseMember-based-te.patch Type: text/x-patch Size: 3798 bytes Desc: not available URL: From abokovoy at redhat.com Wed Aug 10 09:07:42 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Aug 2016 12:07:42 +0300 Subject: [Freeipa-devel] [PATCH 0013-0015] Automatic CSR generation - usability improvements In-Reply-To: <830d6a06-36c8-72c3-e780-9753f2a1bc80@redhat.com> References: <34577c09-7ad2-1658-d88c-ee572c5c7982@redhat.com> <830d6a06-36c8-72c3-e780-9753f2a1bc80@redhat.com> Message-ID: <20160810090742.c7unrg36x6xcsyln@redhat.com> On Wed, 10 Aug 2016, Petr Spacek wrote: >On 9.8.2016 22:07, Ben Lipton wrote: >> Aaand there's a typo in patch 15. Updated version attached. > >Ben, > >it would be great if you can always send whole patch set, including the >patches which were not changed from the previous iteration. > >It is getting quite hard to follow and mix-and-match patches from e-mails into >one patch set. > >As a nice to have addition, you can push the whole patch set to Github (or >somewhere else) so we can just clone the repo and be done with it :-) I concur here. I'm a bit lost which patches have what state, jumping from thread to thread and from response to response. ;) -- / Alexander Bokovoy From abokovoy at redhat.com Wed Aug 10 09:24:41 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Aug 2016 12:24:41 +0300 Subject: [Freeipa-devel] [PATCH] 0024 memory leak in ipapwd plugin In-Reply-To: <57AACBB9.1050608@redhat.com> References: <57AACBB9.1050608@redhat.com> Message-ID: <20160810092441.wmgv6jtrrej7bbxi@redhat.com> On Wed, 10 Aug 2016, thierry bordaz wrote: > >>From 13bb55f9d97f82062f5b496d4164acb562afc7a0 Mon Sep 17 00:00:00 2001 >From: Thierry Bordaz >Date: Tue, 9 Aug 2016 16:46:25 +0200 >Subject: [PATCH] ipa-pwd-extop memory leak during passord update > >During an extend op password update, there is a test if the >user is changing the password is himself. It uses local Slapi_SDN >variable that are not freed >--- > daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 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 6a87a27..2eda6c6 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 >@@ -398,16 +398,20 @@ parse_req_done: > /* if the user changing the password is self, we must request the > * old password and verify it matches the current one before > * proceeding with the password change */ >- bind_sdn = slapi_sdn_new_dn_byref(bindDN); >- target_sdn = slapi_sdn_new_dn_byref(dn); >+ bind_sdn = slapi_sdn_new_dn_byval(bindDN); >+ target_sdn = slapi_sdn_new_dn_byval(dn); > if (!bind_sdn || !target_sdn) { > LOG_OOM(); >+ slapi_sdn_free(&bind_sdn); >+ slapi_sdn_free(&target_sdn); > rc = LDAP_OPERATIONS_ERROR; > goto free_and_return; > } > /* this one will normalize and compare, so difference in case will be > * correctly handled */ > ret = slapi_sdn_compare(bind_sdn, target_sdn); >+ slapi_sdn_free(&bind_sdn); >+ slapi_sdn_free(&target_sdn); > if (ret == 0) { > Slapi_Value *cpw[2] = { NULL, NULL }; > Slapi_Value *pw; I would prefer to unify memory freeing. Because slapi_sdn_compare() can be run with NULL arguments (it will return 0), and slapi_sdn_free() is no-op for NULL argument, you can actually do comparison, then free the SDNs and then do error handling: bind_sdn = slapi_sdn_new_dn_byval(bindDN); target_sdn = slapi_sdn_new_dn_byval(dn); rc = (!bind_sdn || !target_sdn) ? LDAP_OPERATIONS_ERROR : 0; ret = slapi_sdn_compare(bind_sdn, target_sdn); slapi_sdn_free(&bind_sdn); slapi_sdn_free(&target_sdn); if (rc != 0) { LOG_OOM(); goto free_and_return; } if (ret == 0) { .... } >-- >2.7.4 > >-- >Manage your subscription for the Freeipa-devel mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-devel >Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- / Alexander Bokovoy From mbasti at redhat.com Wed Aug 10 10:27:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 10 Aug 2016 12:27:06 +0200 Subject: [Freeipa-devel] [test][patch-0057] test for ticket N 6146 (installing rules with service principals) In-Reply-To: <57AAE7EA.5090604@redhat.com> References: <57AAE7EA.5090604@redhat.com> Message-ID: <745bf2dc-18d4-9f89-b97c-980b447f2823@redhat.com> On 10.08.2016 10:38, Oleg Fayans wrote: > > > Hello, I cannot apply this patch error: ipatests/test_integration/test_certs_in_idoverrides.py: does not exist in index It probably depends on another patch (which one?) Please, use human readable subjects in email, I do not remember from top of my head what #6146 is. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Aug 10 10:51:31 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Aug 2016 13:51:31 +0300 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <20160810070337.kt4auntwnvznvplb@redhat.com> References: <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> <20160808152007.v5fq23paiaa55khf@redhat.com> <57A8A57E.3070003@redhat.com> <57A9BD64.5050308@redhat.com> <20160809113803.2jehpfuxnrg4wozr@redhat.com> <57AACDD9.7070102@redhat.com> <20160810070337.kt4auntwnvznvplb@redhat.com> Message-ID: <20160810105131.74jbejwx5lbv54g6@redhat.com> On Wed, 10 Aug 2016, Alexander Bokovoy wrote: >On Wed, 10 Aug 2016, thierry bordaz wrote: >> >> >>On 08/09/2016 01:38 PM, Alexander Bokovoy wrote: >>>On Tue, 09 Aug 2016, thierry bordaz wrote: >>>> >>>> >>>>On 08/09/2016 12:49 PM, Martin Basti wrote: >>>>> >>>>> >>>>>On 08.08.2016 17:30, thierry bordaz wrote: >>>>>> >>>>>> >>>>>>On 08/08/2016 05:20 PM, Alexander Bokovoy wrote: >>>>>>>On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>> >>>>>>>> >>>>>>>>On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>>>>>>>>On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>>>>>>>>On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>>>>>>>>On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>>>>>>>>On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>When SSSD resolves AD users on behalf of slapi-nis, it can >>>>>>>>>>>>>>accept any >>>>>>>>>>>>>>>user identifier, including user principal >>>>>>>>>>>>>>>name (UPN) which may be >>>>>>>>>>>>>>>different than the canonical user name which SSSD returns. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>As result, the entry created by slapi-nis will be using >>>>>>>>>>>>>>canonical user >>>>>>>>>>>>>>>name but the filter for search will refer >>>>>>>>>>>>>>>to the original (aliased) >>>>>>>>>>>>>>>name. The search will not match the newly created entry. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>The issue is fixed in slapi-nis-0.56.1 by >>>>>>>>>>>>>>>returning two values for >>>>>>>>>>>>>>>'uid' attribute: the canonical one and the >>>>>>>>>>>>>>>aliased one. This way the >>>>>>>>>>>>>>>search will match. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>Standard LDAP schema allows multiple >>>>>>>>>>>>>>>values for 'uid' attribute. We >>>>>>>>>>>>>>>actually use the same trick for 'cn' >>>>>>>>>>>>>>>attribute in the groups map >>>>>>>>>>>>>>>already. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>>should we bump requires to slapi-nis-0.56.1 in freeipa.spec? >>>>>>>>>>>>>No, this is not required. In Fedora we'll >>>>>>>>>>>>>submit a combined update -- >>>>>>>>>>>>>I've built slapi-nis-0.56.1-1 packages for >>>>>>>>>>>>>f24, f25, and rawhide already >>>>>>>>>>>>>but did not submit a Bodhi request. >>>>>>>>>>>>> >>>>>>>>>>>>How is combined updated related to requires to slapi-nis-0.56.1? >>>>>>>>>>>>It will not prevent tu update freeipa without new slapi-nis. >>>>>>>>>>>> >>>>>>>>>>>>e.g. >>>>>>>>>>>>dnf update freeipa-server. >>>>>>>>>>>An update file in FreeIPA that is proposed by this >>>>>>>>>>>patch does not affect >>>>>>>>>>>operation of the older slapi-nis deployment once >>>>>>>>>>>update is applied. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Hi, >>>>>>>>>> >>>>>>>>>>Is '%first' returning the first value of the attribute 'uid' ? >>>>>>>>>>If there are several values (canonical, alias,... ), >>>>>>>>>>does the order matters ? >>>>>>>>>We insert the canonical one first and it seems that 389-ds does not >>>>>>>>>change the order, at least in my tests. You can see >>>>>>>>>the output in the >>>>>>>>>bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 >>>>>>>> >>>>>>>>From ldap pov >>>>>>>>(https://tools.ietf.org/html/rfc4511#section-4.1.7) the >>>>>>>>order of the values is not preserved. >>>>>>>>I think it is a bit risky to rely on a specific order >>>>>>>>especially with complex updates (adding several values >>>>>>>>in a single mod, replace) and replication. >>>>>>>>would it help to add canonical value with a subtype >>>>>>>>(e.g. 'uid;canonical: ') ? >>>>>>>Not sure how what you are mention is relevant here. We talk about >>>>>>>slapi-nis map cache entries which are not modified, replaced or >>>>>>>replicated anywhere by anything other than slapi-nis itself. When >>>>>>>entries are changed by slapi-nis, they are regenerated from scratch. >>>>>>> >>>>>>>Your worries do not apply here. >>>>>>ok. >>>>>>I understand my mistake, I was thinking the compat entry had >>>>>>a associated real entry in ldap and this real entry had two >>>>>>uid values. >>>>>> >>>>> >>>>>So, could you provide ack thierry? >>>>> >>>>>Martin >>>> >>>>Sure but I would have to test first :-) >>>> >>>>Alexander, how can I test this ? >>>slapi-nis 0.56.1-1 packages are available in koji for f24-f26: >>>http://koji.fedoraproject.org/koji/packageinfo?packageID=6609 >> >>Thanks Alexander. So to test this change is there an other way >>(simpler) than setting up AD/trust ? >I don't think so. We don't have UPNs in FreeIPA on the level of identity >lookups and we don't allow to lookup identity by email, so you are left >with using a proper AD trust and UPN suffixes in AD forest. Attached is an updated patch that adds versioned require of slapi-nis which supports the feature. -- / Alexander Bokovoy -------------- next part -------------- From 4a75c02c66e2ecacb0cb3b6e8c2255805e9f68b5 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 4 Aug 2016 09:58:50 +0300 Subject: [PATCH 2/5] support multiple uid values in schema compatibility tree --- freeipa.spec.in | 4 +++- install/updates/10-schema_compat.update | 4 ++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 78ab8ca..c8146e1 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -12,9 +12,11 @@ %if 0%{?rhel} %global samba_version 4.0.5-1 %global selinux_policy_version 3.12.1-153 +%global slapi_nis_version 0.56.0-4 %else %global samba_version 2:4.0.5-1 %global selinux_policy_version 3.13.1-158.4 +%global slapi_nis_version 0.56.1 %endif %define krb5_base_version %(LC_ALL=C rpm -q --qf '%%{VERSION}' krb5-devel | grep -Eo '^[^.]+\.[^.]+') @@ -157,7 +159,7 @@ Requires(pre): systemd-units Requires(post): systemd-units Requires: selinux-policy >= %{selinux_policy_version} Requires(post): selinux-policy-base >= %{selinux_policy_version} -Requires: slapi-nis >= 0.56.0 +Requires: slapi-nis >= %{slapi_nis_version} Requires: pki-ca >= 10.3.3-3 Requires: pki-kra >= 10.3.3-3 Requires(preun): python systemd-units diff --git a/install/updates/10-schema_compat.update b/install/updates/10-schema_compat.update index e4c257d..fbe8703 100644 --- a/install/updates/10-schema_compat.update +++ b/install/updates/10-schema_compat.update @@ -87,3 +87,7 @@ add:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","objectc add:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","") add:schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} add:schema-compat-entry-attribute: %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") + +dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config +add:schema-compat-entry-attribute: uid=%{uid} +replace:schema-compat-entry-rdn: uid=%{uid}::uid=%first("%{uid}") -- 2.7.4 From ofayans at redhat.com Wed Aug 10 11:46:32 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 10 Aug 2016 13:46:32 +0200 Subject: [Freeipa-devel] [test][patch-0057] test for ticket N 6146 (installing rules with service principals) In-Reply-To: <745bf2dc-18d4-9f89-b97c-980b447f2823@redhat.com> References: <57AAE7EA.5090604@redhat.com> <745bf2dc-18d4-9f89-b97c-980b447f2823@redhat.com> Message-ID: <57AB1418.60903@redhat.com> Hi Martin, I am sorry, yes it depends on my patches 0049 and 0050. On 08/10/2016 12:27 PM, Martin Basti wrote: > > > On 10.08.2016 10:38, Oleg Fayans wrote: >> >> >> > Hello, > > I cannot apply this patch > error: ipatests/test_integration/test_certs_in_idoverrides.py: does not > exist in index > It probably depends on another patch (which one?) > > Please, use human readable subjects in email, I do not remember from top > of my head what #6146 is. > > Martin^2 > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Wed Aug 10 11:55:26 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 10 Aug 2016 13:55:26 +0200 Subject: [Freeipa-devel] [PATCH 0061] Removing objectclass expectation for LDAP*ReverseMember based commands In-Reply-To: <4e98844c-410f-7cb8-edfc-30cdc73b6971@redhat.com> References: <4e98844c-410f-7cb8-edfc-30cdc73b6971@redhat.com> Message-ID: <029893dc-732b-e7c4-a814-529267c5d222@redhat.com> On 10.08.2016 11:02, Stanislav Laznicka wrote: > Hello, > > I missed some tests in patch to > https://fedorahosted.org/freeipa/ticket/5892. This patch should fix > the rest of the additional objectclass expectations mentioned in > https://fedorahosted.org/freeipa/ticket/6198. > > ACK Pushed to master: 9f26e395e5ed7aee4fef3abebf6c69c2168ac2f2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From blipton at redhat.com Wed Aug 10 12:52:29 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 10 Aug 2016 08:52:29 -0400 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <837d2da8-d6ad-912a-2b72-a39e9cb87d15@redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> <837d2da8-d6ad-912a-2b72-a39e9cb87d15@redhat.com> Message-ID: The pull request at https://github.com/LiptonB/freeipa/pull/4/commits has been brought up to date (with a force push), and also includes 3 more patches, described below. The patchset is also attached. To make sure that everything applies, I just regenerated the whole set, though there may not be meaningful changes. On 08/03/2016 09:21 AM, Ben Lipton wrote: > On 08/01/2016 11:57 PM, Fraser Tweedale wrote: >> On Fri, Jul 29, 2016 at 11:13:16AM -0400, Ben Lipton wrote: >>> On 07/29/2016 09:39 AM, Petr Spacek wrote: >>>> On 27.7.2016 19:06, Ben Lipton wrote: >>>>> Hi all, >>>>> >>>>> I think the automatic CSR generation feature >>>>> (https://fedorahosted.org/freeipa/ticket/4899, >>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation) >>>>> is >>>>> stable enough to review now. The following are summaries of the >>>>> attached patches: >>>>> 0004: LDAP schema changes for the new feature >>>>> 0005: Basic API for new objects and CSR generation >>>>> 0006: Update install automation to create some default mapping rules >>>>> 0007: Implement the lookups and text processing that generates the >>>>> CSR config >>>>> 0008 and 0009: Implement some actual transformation rules so that >>>>> the feature >>>>> is usable >>>>> 0010: Add a new cert profile for user certs, with mappings >>>>> 0011: Implement import/export of cert profiles with mappings >>>>> 0012: Tests for profile import/export 0013: Add support for generating a full script that makes a CSR, rather than just a config, and use that support to automate the full flow from script generation through cert issuance Usage note: the UI for this could probably use work. I currently have the --helper-args param that allows additional data to be passed to the helper. Commonly this would be something like: Certutil: --helper-args '-d /path/to/nss/db' (precreated with certutil -N -d /path/to/nss/db) Openssl: --helper-args 'd /path/to/keyfile' (precreated with openssl genrsa -out /path/to/keyfile) See the commit message for a full command line. 0014: Allow the feature to be used by non-admin users 0015: Improve error handling by reporting a nice message if the mapping rules are broken, or if the data required to generate the subject DN is missing >>>>> >>>>> Generally speaking, later patches depend on earlier ones, but I don't >>>>> anticipate any problems from committing earlier patches without >>>>> later ones. >>>>> >>>>> If you prefer, you can also comment on the pull request version: >>>>> https://github.com/LiptonB/freeipa/pull/4. Note that I may force >>>>> push on this >>>>> branch. >>>>> >>>>> Allocation of OIDs for schema change also needs review: >>>>> https://code.engineering.redhat.com/gerrit/#/c/80061/ >>>>> >>>>> Known issues: >>>>> - When the requested principal does not have some of the requested >>>>> data, >>>>> produces funny-looking configs with extra commas, empty sections, >>>>> etc. They >>>>> are still accepted by my copies of openssl and certutil, but they >>>>> look ugly. >>>>> - The new objects don't have any ACIs, so for the moment only >>>>> admin can run >>>>> the new commands. Fixed by patch 14 >>>>> - Does not yet have support for prompting user for field values, >>>>> so currently >>>>> all data must come from the database. >>>>> - All processing happens on the server side. As discussed in a >>>>> previous >>>>> thread, it would be desirable to break this out into a library so >>>>> it could be >>>>> used client-side. >>>>> >>>>> Very excited to hear your thoughts! >>>> Hi Ben, >>>> >>>> I wanted to give it a try from user's point of view first, before >>>> diving into >>>> implementation details. Here are some observations: >>> Thanks for giving it a try! This is great feedback. >>>> 0. Design pages are using term "helper" and it is used even as >>>> option in the >>>> example with smartcards. Please fix either design page or the code >>>> so they are >>>> consistent. >>> Good point. In a previous discussion, Alexander remarked that --helper >>> sounded too low-level, but I find that --use sounds very generic and >>> --format doesn't make a lot of sense for ipa cert-request, which never >>> actually gives you the config that's generated. So if they're all >>> going to >>> be the same word, which is probably a good idea, I might be leaning >>> towards >>> --helper, but I'm interested to hear opinions on this. This is called --helper everywhere now. >>>> 1. The "ipa cert-request" command is missing options --autofill and >>>> --use (aka >>>> helper aka format :-) which are mentioned in the design pages. >>> Yeah, I haven't managed to implement much of the UI niceness >>> suggested by >>> the design page. I probably should have mentioned that in the email >>> - all >>> that I expect to be working at this point is 'ipa >>> cert-get-requestdata' and >>> CRUD for the mapping rules/profiles themselves. This is implemented as "ipa cert-build", described above. >>>> 2. "ipa cert_get_requestdata" command passes even without >>>> --profile-id and >>>> generates empty config. I think that this is not expected :-) >>> More expected than you might think :) I'm guessing what's happening >>> is that >>> you're passing a user principal and it's defaulting to the >>> caIPAserviceCert >>> profile, then failing to fill out any of the fields because the data it >>> needs is not there. I agree this isn't great. I was planning to >>> address this >>> by having it throw an error if it can't generate at least the >>> subject of the >>> request, and maybe suggest using a different profile. >>> >>> I chose to have it default to caIPAserviceCert because that's what ipa >>> cert-request does, but maybe that's not as predictable as I thought. >>> >> In general use I think that 'caIPAserviceCert' is unlikely to be >> used a majory of the time, and it is a new command so there are no >> compatibility issues; therefore why not make the profile option >> mandatory? > Fair enough. Ok, a modified patch that changes this (and fixes some > label errors I noticed) is attached. >> >>>> 3. "ipa cert_get_requestdata --format=openssl" prints the text to >>>> stdout >>>> including label "Configuration file contents:". This is hard to use >>>> because >>>> simple redirection like "ipa cert_get_requestdata --format=openssl >>>> > config" >>>> will not give you valid OpenSSL config file - it needs hand-editing. >>>> >>>> It would be good to add --out parameter you envisioned in the >>>> design page. >>>> Please ask jcholast for proper name and semantics :-) With --out >>>> option the >>>> command can be used to generate valid config (or script if certutil >>>> was selected). >>> Agreed. Another example of the UI not being quite right yet. I've been >>> unsure how to handle this, because of certutil taking a command line >>> and >>> openssl a config file. It actually gets even more complicated >>> because, as >>> you point out in the next item, openssl also needs a command in >>> addition to >>> the config file. I'm interested in thinking about how to handle this >>> cleanly >>> from a user perspective. Generating a script, or providing the >>> command lines >>> as hints, might be ways to get around these concerns. As of patch 13, the --out parameter writes a script to a local file, so you no longer have to manually edit the output, or guess about how to invoke certutil/openssl. The scripts take parameters such as where to find the private key, though. >>>> 4. "ipa cert_get_requestdata --format=openssl" could print hint >>>> what OpenSSL >>>> command should be executed on the generated config file. For >>>> testing I've used >>>> command "openssl req -new -out csr -text -config config" (stolen >>>> and modified >>>> from smart card example). Also, as a second hint, it could print >>>> the IPA >>>> command which needs to be used to sign the CSR generated by the >>>> helper. >>> Also agreed, the framework should be able to generate and (for >>> purposes of >>> 'ipa cert-request --autofill') even execute the command required to >>> make the >>> CSR. Fixed-ish. See previous comment. >>> >>>> 5. My naive attempt to get userCert for admin failed: >>>> $ ipa cert_get_requestdata --format=openssl --principal=admin >>>> --profile-id=userCert > usercert.conf >>>> # remove the trailing label >>>> $ openssl req -new -out csr -text -config usercert.conf >>>> $ ipa cert-request --principal=admin --profile-id=userCert >>>> usercert.csr >>>> ipa: ERROR: invalid 'csr': No Common Name was found in subject of >>>> request. >>>> >>>> I'm attaching files generated by the commands above. I did not >>>> modify anything >>>> in the templates or profiles, just tried to use the new profile >>>> added by >>>> freeipa-blipton-0010-Add-a-new-cert-profile-for-users.patch . >>> Hah! This is what I get for thinking I know what the output has to look >>> like, and not testing all the way through to requesting the cert. I'll >>> change the profile to generate a subject with CN= instead of UID=. >>> Updated >>> patch is attached. Unfortunately these rules are only updated at >>> ipa-server-install time, so if you'd like to fix it without >>> reinstalling: >>> >> (Tangential commentary...) Yeah, currently cert-request demands the >> CN. There is a design to relax the requirement to handle empty >> subject names (look at SAN only). IMO it would make sense to accept >> other "obvious" mappings in Subject DN like accepting UID instead of >> CN for user subjects, but that would be a separate RFE. Noone has >> actually asked for it yet :) -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0004-2-Add-schema-to-support-automatic-CSR-generation.patch Type: text/x-patch Size: 6057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0005-3-Add-plugin-for-CSR-generation.patch Type: text/x-patch Size: 20505 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0006-2-Add-generation-rules-to-the-default-cert-profile.patch Type: text/x-patch Size: 8004 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0007-2-Add-code-to-support-generating-configs-using-mapping.patch Type: text/x-patch Size: 10875 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0008-2-Add-jinja2-templates-and-macros-to-support-generatin.patch Type: text/x-patch Size: 7034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0009-2-Add-jinja2-transformation-rules-for-caIPAserviceCert.patch Type: text/x-patch Size: 6224 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0010-3-Add-a-new-cert-profile-for-users.patch Type: text/x-patch Size: 9460 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0011-2-Add-ability-to-import-export-mappings-with-profile.patch Type: text/x-patch Size: 15517 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0012-2-Add-tests-for-mapping-rules-import-export.patch Type: text/x-patch Size: 18907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0013-2-Automate-full-cert-request-flow.patch Type: text/x-patch Size: 11578 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0014-2-Add-ACIs-for-mapping-rules.patch Type: text/x-patch Size: 10693 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0015-3-Improve-error-handling-for-certificate-mapping.patch Type: text/x-patch Size: 5513 bytes Desc: not available URL: From blipton at redhat.com Wed Aug 10 12:54:23 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 10 Aug 2016 08:54:23 -0400 Subject: [Freeipa-devel] [PATCH 0013-0015] Automatic CSR generation - usability improvements In-Reply-To: <20160810090742.c7unrg36x6xcsyln@redhat.com> References: <34577c09-7ad2-1658-d88c-ee572c5c7982@redhat.com> <830d6a06-36c8-72c3-e780-9753f2a1bc80@redhat.com> <20160810090742.c7unrg36x6xcsyln@redhat.com> Message-ID: On 08/10/2016 05:07 AM, Alexander Bokovoy wrote: > On Wed, 10 Aug 2016, Petr Spacek wrote: >> On 9.8.2016 22:07, Ben Lipton wrote: >>> Aaand there's a typo in patch 15. Updated version attached. >> >> Ben, >> >> it would be great if you can always send whole patch set, including the >> patches which were not changed from the previous iteration. >> >> It is getting quite hard to follow and mix-and-match patches from >> e-mails into >> one patch set. >> >> As a nice to have addition, you can push the whole patch set to >> Github (or >> somewhere else) so we can just clone the repo and be done with it :-) > I concur here. I'm a bit lost which patches have what state, jumping > from thread to thread and from response to response. ;) > > Ok, I've merged everything into the older thread, and updated the github branch with all the changes, old and new. I hope that will be easier to follow. Sorry about the confusion! From tbordaz at redhat.com Wed Aug 10 14:37:05 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 10 Aug 2016 16:37:05 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <20160810105131.74jbejwx5lbv54g6@redhat.com> References: <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> <20160808152007.v5fq23paiaa55khf@redhat.com> <57A8A57E.3070003@redhat.com> <57A9BD64.5050308@redhat.com> <20160809113803.2jehpfuxnrg4wozr@redhat.com> <57AACDD9.7070102@redhat.com> <20160810070337.kt4auntwnvznvplb@redhat.com> <20160810105131.74jbejwx5lbv54g6@redhat.com> Message-ID: <57AB3C11.9030008@redhat.com> On 08/10/2016 12:51 PM, Alexander Bokovoy wrote: > On Wed, 10 Aug 2016, Alexander Bokovoy wrote: >> On Wed, 10 Aug 2016, thierry bordaz wrote: >>> >>> >>> On 08/09/2016 01:38 PM, Alexander Bokovoy wrote: >>>> On Tue, 09 Aug 2016, thierry bordaz wrote: >>>>> >>>>> >>>>> On 08/09/2016 12:49 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08.08.2016 17:30, thierry bordaz wrote: >>>>>>> >>>>>>> >>>>>>> On 08/08/2016 05:20 PM, Alexander Bokovoy wrote: >>>>>>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>>>>>>>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>>>>>>>>> On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>>>>>>>>> On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>>>>>>>>> On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>> When SSSD resolves AD users on behalf of slapi-nis, it can >>>>>>>>>>>>>>> accept any >>>>>>>>>>>>>>>> user identifier, including user principal name (UPN) >>>>>>>>>>>>>>>> which may be >>>>>>>>>>>>>>>> different than the canonical user name which SSSD returns. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As result, the entry created by slapi-nis will be using >>>>>>>>>>>>>>> canonical user >>>>>>>>>>>>>>>> name but the filter for search will refer to the >>>>>>>>>>>>>>>> original (aliased) >>>>>>>>>>>>>>>> name. The search will not match the newly created entry. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The issue is fixed in slapi-nis-0.56.1 by returning >>>>>>>>>>>>>>>> two values for >>>>>>>>>>>>>>>> 'uid' attribute: the canonical one and the aliased one. >>>>>>>>>>>>>>>> This way the >>>>>>>>>>>>>>>> search will match. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Standard LDAP schema allows multiple values for 'uid' >>>>>>>>>>>>>>>> attribute. We >>>>>>>>>>>>>>>> actually use the same trick for 'cn' attribute in the >>>>>>>>>>>>>>>> groups map >>>>>>>>>>>>>>>> already. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> should we bump requires to slapi-nis-0.56.1 in >>>>>>>>>>>>>>> freeipa.spec? >>>>>>>>>>>>>> No, this is not required. In Fedora we'll submit a >>>>>>>>>>>>>> combined update -- >>>>>>>>>>>>>> I've built slapi-nis-0.56.1-1 packages for f24, f25, and >>>>>>>>>>>>>> rawhide already >>>>>>>>>>>>>> but did not submit a Bodhi request. >>>>>>>>>>>>>> >>>>>>>>>>>>> How is combined updated related to requires to >>>>>>>>>>>>> slapi-nis-0.56.1? >>>>>>>>>>>>> It will not prevent tu update freeipa without new slapi-nis. >>>>>>>>>>>>> >>>>>>>>>>>>> e.g. >>>>>>>>>>>>> dnf update freeipa-server. >>>>>>>>>>>> An update file in FreeIPA that is proposed by this patch >>>>>>>>>>>> does not affect >>>>>>>>>>>> operation of the older slapi-nis deployment once update is >>>>>>>>>>>> applied. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Is '%first' returning the first value of the attribute 'uid' ? >>>>>>>>>>> If there are several values (canonical, alias,... ), does >>>>>>>>>>> the order matters ? >>>>>>>>>> We insert the canonical one first and it seems that 389-ds >>>>>>>>>> does not >>>>>>>>>> change the order, at least in my tests. You can see the >>>>>>>>>> output in the >>>>>>>>>> bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 >>>>>>>>> >>>>>>>>> From ldap pov >>>>>>>>> (https://tools.ietf.org/html/rfc4511#section-4.1.7) the order >>>>>>>>> of the values is not preserved. >>>>>>>>> I think it is a bit risky to rely on a specific order >>>>>>>>> especially with complex updates (adding several values in a >>>>>>>>> single mod, replace) and replication. >>>>>>>>> would it help to add canonical value with a subtype (e.g. >>>>>>>>> 'uid;canonical: ') ? >>>>>>>> Not sure how what you are mention is relevant here. We talk about >>>>>>>> slapi-nis map cache entries which are not modified, replaced or >>>>>>>> replicated anywhere by anything other than slapi-nis itself. When >>>>>>>> entries are changed by slapi-nis, they are regenerated from >>>>>>>> scratch. >>>>>>>> >>>>>>>> Your worries do not apply here. >>>>>>> ok. >>>>>>> I understand my mistake, I was thinking the compat entry had a >>>>>>> associated real entry in ldap and this real entry had two uid >>>>>>> values. >>>>>>> >>>>>> >>>>>> So, could you provide ack thierry? >>>>>> >>>>>> Martin >>>>> >>>>> Sure but I would have to test first :-) >>>>> >>>>> Alexander, how can I test this ? >>>> slapi-nis 0.56.1-1 packages are available in koji for f24-f26: >>>> http://koji.fedoraproject.org/koji/packageinfo?packageID=6609 >>> >>> Thanks Alexander. So to test this change is there an other way >>> (simpler) than setting up AD/trust ? >> I don't think so. We don't have UPNs in FreeIPA on the level of identity >> lookups and we don't allow to lookup identity by email, so you are left >> with using a proper AD trust and UPN suffixes in AD forest. > Attached is an updated patch that adds versioned require of slapi-nis > which supports the feature. > > Thanks to Lenka, I was able to test the patch with AD trust and a UPN suffix. The tests looks good as 'getent' on a AD user returns user at ADdomain. Now if I remove the config change in "cn=users,cn=Schema Compatibility,cn=plugins,cn=config", I get the same results i.e: getent passwd upnuser at UPNsuffix.com upnuser at dom-221.idm.lab.eng.brq.redhat.com:*:1965201133:1965201133:UPN User:/: How can I check slapi-nis gets the first value ? thanks thierry From mbasti at redhat.com Wed Aug 10 14:56:54 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 10 Aug 2016 16:56:54 +0200 Subject: [Freeipa-devel] [PATCH] 965 ca-less tests: fix getting cert in pem format from nssdb In-Reply-To: <9264a4ac-c8b0-a105-815c-f35e4f9fffcf@redhat.com> References: <6a85a454-b0b0-05b2-8497-9296c08cbea7@redhat.com> <9264a4ac-c8b0-a105-815c-f35e4f9fffcf@redhat.com> Message-ID: <15c26d9b-9735-639b-159f-35a2901d3acd@redhat.com> On 06.08.2016 13:16, Petr Vobornik wrote: > On 08/06/2016 12:32 PM, Petr Vobornik wrote: >> usage of ipautil.run in get_pem methond of ca-less tests was not >> refactored when the ipautil.run was refactored in >> 099cf98307d4b2f0ace5d5e28754f264808bf59d >> >> This results in failure of all CA-less test (probably). >> >> Patch is untested though. >> >> https://fedorahosted.org/freeipa/ticket/6177 >> > Original patch doesn't fix the issue. Main culprit is that output is > captured only if capture_output=True is passed to ipautil.run > > Previous patch therefore just replaced old usage to new usage. > > Attaching fixed path. > > ACK Test, instant triage to 4.3 Pushed to master: 6217d680da5b121ba39e48f8823f21a639261584 Pushed to ipa-4-3: 42d3ec37f5a2692a51cd7db878b7b745d8d4c846 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Wed Aug 10 15:27:16 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 10 Aug 2016 17:27:16 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <57AB3C11.9030008@redhat.com> References: <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> <20160808152007.v5fq23paiaa55khf@redhat.com> <57A8A57E.3070003@redhat.com> <57A9BD64.5050308@redhat.com> <20160809113803.2jehpfuxnrg4wozr@redhat.com> <57AACDD9.7070102@redhat.com> <20160810070337.kt4auntwnvznvplb@redhat.com> <20160810105131.74jbejwx5lbv54g6@redhat.com> <57AB3C11.9030008@redhat.com> Message-ID: <57AB47D4.5030400@redhat.com> On 08/10/2016 04:37 PM, thierry bordaz wrote: > > > On 08/10/2016 12:51 PM, Alexander Bokovoy wrote: >> On Wed, 10 Aug 2016, Alexander Bokovoy wrote: >>> On Wed, 10 Aug 2016, thierry bordaz wrote: >>>> >>>> >>>> On 08/09/2016 01:38 PM, Alexander Bokovoy wrote: >>>>> On Tue, 09 Aug 2016, thierry bordaz wrote: >>>>>> >>>>>> >>>>>> On 08/09/2016 12:49 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08.08.2016 17:30, thierry bordaz wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/08/2016 05:20 PM, Alexander Bokovoy wrote: >>>>>>>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>>>>>>>>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>>>>>>>>>> On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>>>>>>>>>> On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>>>>>>>>>> On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>>> When SSSD resolves AD users on behalf of slapi-nis, it >>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>> accept any >>>>>>>>>>>>>>>>> user identifier, including user principal name (UPN) >>>>>>>>>>>>>>>>> which may be >>>>>>>>>>>>>>>>> different than the canonical user name which SSSD >>>>>>>>>>>>>>>>> returns. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As result, the entry created by slapi-nis will be using >>>>>>>>>>>>>>>> canonical user >>>>>>>>>>>>>>>>> name but the filter for search will refer to the >>>>>>>>>>>>>>>>> original (aliased) >>>>>>>>>>>>>>>>> name. The search will not match the newly created entry. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The issue is fixed in slapi-nis-0.56.1 by returning >>>>>>>>>>>>>>>>> two values for >>>>>>>>>>>>>>>>> 'uid' attribute: the canonical one and the aliased >>>>>>>>>>>>>>>>> one. This way the >>>>>>>>>>>>>>>>> search will match. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Standard LDAP schema allows multiple values for 'uid' >>>>>>>>>>>>>>>>> attribute. We >>>>>>>>>>>>>>>>> actually use the same trick for 'cn' attribute in the >>>>>>>>>>>>>>>>> groups map >>>>>>>>>>>>>>>>> already. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> should we bump requires to slapi-nis-0.56.1 in >>>>>>>>>>>>>>>> freeipa.spec? >>>>>>>>>>>>>>> No, this is not required. In Fedora we'll submit a >>>>>>>>>>>>>>> combined update -- >>>>>>>>>>>>>>> I've built slapi-nis-0.56.1-1 packages for f24, f25, and >>>>>>>>>>>>>>> rawhide already >>>>>>>>>>>>>>> but did not submit a Bodhi request. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> How is combined updated related to requires to >>>>>>>>>>>>>> slapi-nis-0.56.1? >>>>>>>>>>>>>> It will not prevent tu update freeipa without new slapi-nis. >>>>>>>>>>>>>> >>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>> dnf update freeipa-server. >>>>>>>>>>>>> An update file in FreeIPA that is proposed by this patch >>>>>>>>>>>>> does not affect >>>>>>>>>>>>> operation of the older slapi-nis deployment once update is >>>>>>>>>>>>> applied. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Is '%first' returning the first value of the attribute 'uid' ? >>>>>>>>>>>> If there are several values (canonical, alias,... ), does >>>>>>>>>>>> the order matters ? >>>>>>>>>>> We insert the canonical one first and it seems that 389-ds >>>>>>>>>>> does not >>>>>>>>>>> change the order, at least in my tests. You can see the >>>>>>>>>>> output in the >>>>>>>>>>> bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 >>>>>>>>>> >>>>>>>>>> From ldap pov >>>>>>>>>> (https://tools.ietf.org/html/rfc4511#section-4.1.7) the order >>>>>>>>>> of the values is not preserved. >>>>>>>>>> I think it is a bit risky to rely on a specific order >>>>>>>>>> especially with complex updates (adding several values in a >>>>>>>>>> single mod, replace) and replication. >>>>>>>>>> would it help to add canonical value with a subtype (e.g. >>>>>>>>>> 'uid;canonical: ') ? >>>>>>>>> Not sure how what you are mention is relevant here. We talk about >>>>>>>>> slapi-nis map cache entries which are not modified, replaced or >>>>>>>>> replicated anywhere by anything other than slapi-nis itself. When >>>>>>>>> entries are changed by slapi-nis, they are regenerated from >>>>>>>>> scratch. >>>>>>>>> >>>>>>>>> Your worries do not apply here. >>>>>>>> ok. >>>>>>>> I understand my mistake, I was thinking the compat entry had a >>>>>>>> associated real entry in ldap and this real entry had two uid >>>>>>>> values. >>>>>>>> >>>>>>> >>>>>>> So, could you provide ack thierry? >>>>>>> >>>>>>> Martin >>>>>> >>>>>> Sure but I would have to test first :-) >>>>>> >>>>>> Alexander, how can I test this ? >>>>> slapi-nis 0.56.1-1 packages are available in koji for f24-f26: >>>>> http://koji.fedoraproject.org/koji/packageinfo?packageID=6609 >>>> >>>> Thanks Alexander. So to test this change is there an other way >>>> (simpler) than setting up AD/trust ? >>> I don't think so. We don't have UPNs in FreeIPA on the level of >>> identity >>> lookups and we don't allow to lookup identity by email, so you are left >>> with using a proper AD trust and UPN suffixes in AD forest. >> Attached is an updated patch that adds versioned require of slapi-nis >> which supports the feature. >> >> > > Thanks to Lenka, I was able to test the patch with AD trust and a UPN > suffix. > > The tests looks good as 'getent' on a AD user returns user at ADdomain. > > Now if I remove the config change in "cn=users,cn=Schema > Compatibility,cn=plugins,cn=config", I get the same results i.e: > getent passwd upnuser at UPNsuffix.com > upnuser at dom-221.idm.lab.eng.brq.redhat.com:*:1965201133:1965201133:UPN > User:/: > > > How can I check slapi-nis gets the first value ? > > thanks > thierry acceptance is now completed (successfully). ACK From mbasti at redhat.com Wed Aug 10 15:48:31 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 10 Aug 2016 17:48:31 +0200 Subject: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate In-Reply-To: <47d419bd-2b40-8573-2c65-c22a255f5607@redhat.com> References: <1004948019.9643194.1469705403940.JavaMail.zimbra@redhat.com> <11d0579b-2ca2-af88-ed97-2efa477290c0@redhat.com> <529785673.9646711.1469705707399.JavaMail.zimbra@redhat.com> <47d419bd-2b40-8573-2c65-c22a255f5607@redhat.com> Message-ID: <21609031-d13b-eb27-f945-513d244d18cf@redhat.com> On 08.08.2016 10:30, Martin Basti wrote: > > > > On 02.08.2016 14:50, Lenka Doudova wrote: >> >> >> >> On 07/29/2016 11:43 AM, Lenka Doudova wrote: >>> >>> >>> >>> On 07/29/2016 11:41 AM, Lenka Doudova wrote: >>>> >>>> On 07/28/2016 01:35 PM, Peter Lacko wrote: >>>>> Hops, fixed. >>>>> >>>>> Peter >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "Lenka Doudova" >>>>> To:freeipa-devel at redhat.com >>>>> Sent: Thursday, July 28, 2016 1:32:25 PM >>>>> Subject: Re: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate >>>>> >>>>> Hi, >>>>> >>>>> I cannot find any attached patch :) >>>>> >>>>> Lenka >>>>> >>>>> >>>>> On 07/28/2016 01:30 PM, Peter Lacko wrote: >>>>>> Attached you can find a patch adding test for URIs in generated certificate >>>>>> ipatests/test_xmlrpc/test_cert_plugin.py >>>>>> Since I'm leaving Red Hat in end of July, I won't be able to modify this patch anymore. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Peter >>>>>> >>>>> >>>>> >>>> Hi, >>>> >>>> NACK. Code looks fine and works well on master branch, but patch >>>> does not apply on 4-3 and 4-2 branches. >>>> Peter left the company but claimed he can fix the patch if >>>> necessary, I'll communicate it with him or fix it myself. >>>> >>>> Lenka >>>> >>>> >>> Oh, and forgot this one - PEP8 error: >>> ./ipatests/test_xmlrpc/test_cert_plugin.py:191:80: E501 line too >>> long (105 > 79 characters) >>> >>> Lenka >>> >>> >> Hi, >> >> since Peter has quit already, I took it upon myself to do minor fix >> and rebase to the patch. >> 1) i removed pylint disable comments from the patch, as they were >> unnecessary (this also solved PEP8 error) >> 2) I rebased the patch to be applicable for ipa-4-3 branch. >> Original functionality of the patch remains unchanged. >> >> Both fixed patches attached. >> >> Lenka >> >> > > Hello, > > 1) > This is not needed > + global sn > + > + result = api.Command.cert_show(sn, out=unicode(self.certfile)) > > you need the global statement only for write access. But sn is not assigned in this code block. > > 2) > I prefer to use instance attributes (self.sn) instead of global variables As we figured out, pytest creates for each test new instance of class, so 2) will not fork. Please fix only 1), sorry. Martin^2 > > Martin^2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Wed Aug 10 16:21:54 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 10 Aug 2016 10:21:54 -0600 Subject: [Freeipa-devel] Karma Requests for Dogtag 10.3.5-1 and ldapjdk Message-ID: <42de6a29-ce3d-9cc7-9e48-e5ba123e8491@redhat.com> *The following candidate builds of Dogtag 10.3.5 and ldapjdk on Fedora 24, 25, and 26 (rawhide) consist of the following:* * *Fedora 24:* o *dogtag-pki-10.3.5-1.fc24 * o *dogtag-pki-theme-10.3.5-1.fc24 * o *pki-core-10.3.5-1.fc24 * o *pki-console-10.3.5-1.fc24 * o *ldapjdk-4.18-19.fc24 * * *Fedora 25:* o *dogtag-pki-10.3.5-1.fc25 * o *dogtag-pki-theme-10.3.5-1.fc25 * o *pki-core-10.3.5-1.fc25 * o *pki-console-10.3.5-1.fc25 * o *ldapjdk-4.18-19.fc25 * * *Fedora 26 (rawhide):* o *dogtag-pki-10.3.5-1.fc26 * o *dogtag-pki-theme-10.3.5-1.fc26 * o *pki-core-10.3.5-1.fc26 * o *pki-console-10.3.5-1.fc26 * o *ldapjdk-4.18-19.fc26 * *Please provide Karma for the following builds:* * *Fedora 24:* o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-059eb8aaee dogtag-pki-10.3.5-1.fc24 * o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f1baf574f dogtag-pki-theme-10.3.5-1.fc24 * o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-4d226a5f7e pki-core-10.3.5-1.fc24 * o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-dd16599bc7 pki-console-10.3.5-1.fc24 * o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-1835df9b39 ldapjdk-4.18-19.fc24 * * *Fedora 25:* o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-85261e13c5 dogtag-pki-10.3.5-1.fc25* o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f0224b152 dogtag-pki-theme-10.3.5-1.fc25* o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-0a384ead60 pki-core-10.3.5-1.fc25 * o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-849cbeecb1 pki-console-10.3.5-1.fc25 * o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f6bc9b601 ldapjdk-4.18-19.fc25 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Wed Aug 10 16:26:11 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 10 Aug 2016 18:26:11 +0200 Subject: [Freeipa-devel] [PATCH] 0024 memory leak in ipapwd plugin In-Reply-To: <20160810092441.wmgv6jtrrej7bbxi@redhat.com> References: <57AACBB9.1050608@redhat.com> <20160810092441.wmgv6jtrrej7bbxi@redhat.com> Message-ID: <57AB55A3.6040305@redhat.com> On 08/10/2016 11:24 AM, Alexander Bokovoy wrote: > On Wed, 10 Aug 2016, thierry bordaz wrote: >> > >>> From 13bb55f9d97f82062f5b496d4164acb562afc7a0 Mon Sep 17 00:00:00 2001 >> From: Thierry Bordaz >> Date: Tue, 9 Aug 2016 16:46:25 +0200 >> Subject: [PATCH] ipa-pwd-extop memory leak during passord update >> >> During an extend op password update, there is a test if the >> user is changing the password is himself. It uses local Slapi_SDN >> variable that are not freed >> --- >> daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 8 ++++++-- >> 1 file changed, 6 insertions(+), 2 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 6a87a27..2eda6c6 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 >> @@ -398,16 +398,20 @@ parse_req_done: >> /* if the user changing the password is self, we must request >> the >> * old password and verify it matches the current one before >> * proceeding with the password change */ >> - bind_sdn = slapi_sdn_new_dn_byref(bindDN); >> - target_sdn = slapi_sdn_new_dn_byref(dn); >> + bind_sdn = slapi_sdn_new_dn_byval(bindDN); >> + target_sdn = slapi_sdn_new_dn_byval(dn); >> if (!bind_sdn || !target_sdn) { >> LOG_OOM(); >> + slapi_sdn_free(&bind_sdn); >> + slapi_sdn_free(&target_sdn); >> rc = LDAP_OPERATIONS_ERROR; >> goto free_and_return; >> } >> /* this one will normalize and compare, so difference in case >> will be >> * correctly handled */ >> ret = slapi_sdn_compare(bind_sdn, target_sdn); >> + slapi_sdn_free(&bind_sdn); >> + slapi_sdn_free(&target_sdn); >> if (ret == 0) { >> Slapi_Value *cpw[2] = { NULL, NULL }; >> Slapi_Value *pw; > I would prefer to unify memory freeing. Because slapi_sdn_compare() can > be run with NULL arguments (it will return 0), and slapi_sdn_free() is > no-op for NULL argument, you can actually do comparison, then free the > SDNs and then do error handling: > > > bind_sdn = slapi_sdn_new_dn_byval(bindDN); > target_sdn = slapi_sdn_new_dn_byval(dn); > > rc = (!bind_sdn || !target_sdn) ? LDAP_OPERATIONS_ERROR : 0; > ret = slapi_sdn_compare(bind_sdn, target_sdn); > > slapi_sdn_free(&bind_sdn); > slapi_sdn_free(&target_sdn); > > if (rc != 0) { > LOG_OOM(); > goto free_and_return; > } > > if (ret == 0) { > .... > } > > > >> -- >> 2.7.4 >> > >> -- >> Manage your subscription for the Freeipa-devel mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > > Thanks again Alexander for the review. Here is the revisited patch -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-44-tbordaz-024-2-ipa-pwd-extop-memory-leak-during-passord-update.patch Type: text/x-patch Size: 2115 bytes Desc: not available URL: From blipton at redhat.com Wed Aug 10 16:59:21 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 10 Aug 2016 12:59:21 -0400 Subject: [Freeipa-devel] Karma Requests for Dogtag 10.3.5-1 and ldapjdk In-Reply-To: <42de6a29-ce3d-9cc7-9e48-e5ba123e8491@redhat.com> References: <42de6a29-ce3d-9cc7-9e48-e5ba123e8491@redhat.com> Message-ID: <45f190c0-04b8-a669-9baa-3ce9e7434e78@redhat.com> On 08/10/2016 12:21 PM, Matthew Harmsen wrote: > > *The following candidate builds of Dogtag 10.3.5 and ldapjdk on Fedora > 24, 25, and 26 (rawhide) consist of the following:* > > * *Fedora 24:* > o *dogtag-pki-10.3.5-1.fc24 > * > o *dogtag-pki-theme-10.3.5-1.fc24 > * > o *pki-core-10.3.5-1.fc24 > * > o *pki-console-10.3.5-1.fc24 > * > o *ldapjdk-4.18-19.fc24 > * > * *Fedora 25:* > o *dogtag-pki-10.3.5-1.fc25 > * > o *dogtag-pki-theme-10.3.5-1.fc25 > * > o *pki-core-10.3.5-1.fc25 > * > o *pki-console-10.3.5-1.fc25 > * > o *ldapjdk-4.18-19.fc25 > * > * *Fedora 26 (rawhide):* > o *dogtag-pki-10.3.5-1.fc26 > * > o *dogtag-pki-theme-10.3.5-1.fc26 > * > o *pki-core-10.3.5-1.fc26 > * > o *pki-console-10.3.5-1.fc26 > * > o *ldapjdk-4.18-19.fc26 > * > > *Please provide Karma for the following builds:* > > * *Fedora 24:* > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-059eb8aaee > dogtag-pki-10.3.5-1.fc24 > * > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f1baf574f > dogtag-pki-theme-10.3.5-1.fc24 > * > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-4d226a5f7e > pki-core-10.3.5-1.fc24 > * > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-dd16599bc7 > pki-console-10.3.5-1.fc24 > * > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-1835df9b39 > ldapjdk-4.18-19.fc24 > > * > * *Fedora 25:* > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-85261e13c5 > dogtag-pki-10.3.5-1.fc25* > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f0224b152 > dogtag-pki-theme-10.3.5-1.fc25* > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-0a384ead60 > pki-core-10.3.5-1.fc25 > * > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-849cbeecb1 > pki-console-10.3.5-1.fc25 > * > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f6bc9b601 > ldapjdk-4.18-19.fc25 > > * > > > On Fedora 24 I am unable to upgrade to these packages without manual intervention: [root at vm freeipa]# dnf update --allowerasing --best Last metadata expiration check: 2:08:29 ago on Wed Aug 10 16:38:24 2016. Error: nothing provides resteasy-atom-provider >= 3.0.17-1 needed by pki-base-java-10.3.5-1.fc24.noarch. package pki-tools-10.3.5-1.fc24.x86_64 requires pki-base-java = 10.3.5-1.fc24, but none of the providers can be installed. nothing provides resteasy-atom-provider >= 3.0.17-1 needed by pki-base-java-10.3.5-1.fc24.noarch. nothing provides resteasy-atom-provider >= 3.0.17-1 needed by pki-base-java-10.3.5-1.fc24.noarch. nothing provides resteasy-atom-provider >= 3.0.17-1 needed by pki-base-java-10.3.5-1.fc24.noarch. nothing provides resteasy-atom-provider >= 3.0.17-1 needed by pki-base-java-10.3.5-1.fc24.noarch [root at vm freeipa]# rpm -q resteasy-atom-provider resteasy-atom-provider-3.0.6-11.fc24.noarch Am I doing something wrong, or does the new resteasy need to be added back to testing? (https://bodhi.fedoraproject.org/updates/FEDORA-2016-d80872c309) Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Aug 10 17:19:27 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Aug 2016 20:19:27 +0300 Subject: [Freeipa-devel] [PATCH] 0024 memory leak in ipapwd plugin In-Reply-To: <57AB55A3.6040305@redhat.com> References: <57AACBB9.1050608@redhat.com> <20160810092441.wmgv6jtrrej7bbxi@redhat.com> <57AB55A3.6040305@redhat.com> Message-ID: <20160810171927.fzjktnorevhlv46e@redhat.com> On Wed, 10 Aug 2016, thierry bordaz wrote: > > >On 08/10/2016 11:24 AM, Alexander Bokovoy wrote: >>On Wed, 10 Aug 2016, thierry bordaz wrote: >>> >> >>>>From 13bb55f9d97f82062f5b496d4164acb562afc7a0 Mon Sep 17 00:00:00 2001 >>>From: Thierry Bordaz >>>Date: Tue, 9 Aug 2016 16:46:25 +0200 >>>Subject: [PATCH] ipa-pwd-extop memory leak during passord update >>> >>>During an extend op password update, there is a test if the >>>user is changing the password is himself. It uses local Slapi_SDN >>>variable that are not freed >>>--- >>>daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 8 ++++++-- >>>1 file changed, 6 insertions(+), 2 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 6a87a27..2eda6c6 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 >>>@@ -398,16 +398,20 @@ parse_req_done: >>> /* if the user changing the password is self, we must >>>request the >>> * old password and verify it matches the current one before >>> * proceeding with the password change */ >>>- bind_sdn = slapi_sdn_new_dn_byref(bindDN); >>>- target_sdn = slapi_sdn_new_dn_byref(dn); >>>+ bind_sdn = slapi_sdn_new_dn_byval(bindDN); >>>+ target_sdn = slapi_sdn_new_dn_byval(dn); >>> if (!bind_sdn || !target_sdn) { >>> LOG_OOM(); >>>+ slapi_sdn_free(&bind_sdn); >>>+ slapi_sdn_free(&target_sdn); >>> rc = LDAP_OPERATIONS_ERROR; >>> goto free_and_return; >>> } >>> /* this one will normalize and compare, so difference in >>>case will be >>> * correctly handled */ >>> ret = slapi_sdn_compare(bind_sdn, target_sdn); >>>+ slapi_sdn_free(&bind_sdn); >>>+ slapi_sdn_free(&target_sdn); >>> if (ret == 0) { >>> Slapi_Value *cpw[2] = { NULL, NULL }; >>> Slapi_Value *pw; >>I would prefer to unify memory freeing. Because slapi_sdn_compare() can >>be run with NULL arguments (it will return 0), and slapi_sdn_free() is >>no-op for NULL argument, you can actually do comparison, then free the >>SDNs and then do error handling: >> >> >> bind_sdn = slapi_sdn_new_dn_byval(bindDN); >> target_sdn = slapi_sdn_new_dn_byval(dn); >> >> rc = (!bind_sdn || !target_sdn) ? LDAP_OPERATIONS_ERROR : 0; >> ret = slapi_sdn_compare(bind_sdn, target_sdn); >> >> slapi_sdn_free(&bind_sdn); >> slapi_sdn_free(&target_sdn); >> >> if (rc != 0) { >> LOG_OOM(); >> goto free_and_return; >> } >> >> if (ret == 0) { >> .... >> } >> >> >> >>>-- >>>2.7.4 >>> >> >>>-- >>>Manage your subscription for the Freeipa-devel mailing list: >>>https://www.redhat.com/mailman/listinfo/freeipa-devel >>>Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code >> >> >Thanks again Alexander for the review. Here is the revisited patch >From db4211d855b4d21354dc619952b2b2e1ad31f3b9 Mon Sep 17 00:00:00 2001 >From: Thierry Bordaz >Date: Tue, 9 Aug 2016 16:46:25 +0200 >Subject: [PATCH] ipa-pwd-extop memory leak during passord update > >During an extend op password update, there is a test if the >user is changing the password is himself. It uses local Slapi_SDN >variable that are not freed >--- > .../ipa-pwd-extop/ipa_pwd_extop.c | 24 +++++++++++++++------- > 1 file changed, 17 insertions(+), 7 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 6a87a27..eaca0dc 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 >@@ -398,16 +398,26 @@ parse_req_done: > /* if the user changing the password is self, we must request the > * old password and verify it matches the current one before > * proceeding with the password change */ >- bind_sdn = slapi_sdn_new_dn_byref(bindDN); >- target_sdn = slapi_sdn_new_dn_byref(dn); >- if (!bind_sdn || !target_sdn) { >- LOG_OOM(); >- rc = LDAP_OPERATIONS_ERROR; >- goto free_and_return; >- } >+ bind_sdn = slapi_sdn_new_dn_byval(bindDN); >+ target_sdn = slapi_sdn_new_dn_byval(dn); >+ >+ rc = (!bind_sdn || !target_sdn) ? LDAP_OPERATIONS_ERROR : 0; >+ > /* this one will normalize and compare, so difference in case will be > * correctly handled */ > ret = slapi_sdn_compare(bind_sdn, target_sdn); >+ >+ slapi_sdn_free(&bind_sdn); >+ slapi_sdn_free(&target_sdn); >+ >+ /* rc should always be 0 (else slapi_sdn_new_dn_byref should have sigsev) >+ * but if we end in rc==LDAP_OPERATIONS_ERROR be sure to stop here >+ * because ret is not significant */ A short note here. You talk about slapi_sdn_new_dn_byref() but your patch replaces that with slapi_sdn_new_dn_byval(). Does the comment still apply? >+ if (rc != 0) { >+ LOG_OOM(); >+ goto free_and_return; >+ } >+ > if (ret == 0) { > Slapi_Value *cpw[2] = { NULL, NULL }; > Slapi_Value *pw; >-- >2.7.4 > -- / Alexander Bokovoy From ofayans at redhat.com Wed Aug 10 18:32:58 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 10 Aug 2016 20:32:58 +0200 Subject: [Freeipa-devel] [Test][patch-0058] Fixed topology tests failures in CI Message-ID: <57AB735A.3000101@redhat.com> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0058-Fixed-expected-segment-name.patch Type: text/x-patch Size: 1501 bytes Desc: not available URL: From mharmsen at redhat.com Wed Aug 10 23:31:40 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 10 Aug 2016 17:31:40 -0600 Subject: [Freeipa-devel] Karma Requests for Dogtag 10.3.5-1 and ldapjdk In-Reply-To: <45f190c0-04b8-a669-9baa-3ce9e7434e78@redhat.com> References: <42de6a29-ce3d-9cc7-9e48-e5ba123e8491@redhat.com> <45f190c0-04b8-a669-9baa-3ce9e7434e78@redhat.com> Message-ID: <3f482874-a623-671d-4dc1-0beb063ef362@redhat.com> On 08/10/2016 10:59 AM, Ben Lipton wrote: > On 08/10/2016 12:21 PM, Matthew Harmsen wrote: >> >> *The following candidate builds of Dogtag 10.3.5 and ldapjdk on >> Fedora 24, 25, and 26 (rawhide) consist of the following:* >> >> * *Fedora 24:* >> o *dogtag-pki-10.3.5-1.fc24 >> * >> o *dogtag-pki-theme-10.3.5-1.fc24 >> * >> o *pki-core-10.3.5-1.fc24 >> * >> o *pki-console-10.3.5-1.fc24 >> * >> o *ldapjdk-4.18-19.fc24 >> * >> * *Fedora 25:* >> o *dogtag-pki-10.3.5-1.fc25 >> * >> o *dogtag-pki-theme-10.3.5-1.fc25 >> * >> o *pki-core-10.3.5-1.fc25 >> * >> o *pki-console-10.3.5-1.fc25 >> * >> o *ldapjdk-4.18-19.fc25 >> * >> * *Fedora 26 (rawhide):* >> o *dogtag-pki-10.3.5-1.fc26 >> * >> o *dogtag-pki-theme-10.3.5-1.fc26 >> * >> o *pki-core-10.3.5-1.fc26 >> * >> o *pki-console-10.3.5-1.fc26 >> * >> o *ldapjdk-4.18-19.fc26 >> * >> >> *Please provide Karma for the following builds:* >> >> * *Fedora 24:* >> o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-059eb8aaee >> dogtag-pki-10.3.5-1.fc24 >> * >> o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f1baf574f >> dogtag-pki-theme-10.3.5-1.fc24 >> * >> o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-4d226a5f7e >> pki-core-10.3.5-1.fc24 >> * >> o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-dd16599bc7 >> pki-console-10.3.5-1.fc24 >> * >> o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-1835df9b39 >> ldapjdk-4.18-19.fc24 >> >> * >> * *Fedora 25:* >> o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-85261e13c5 >> dogtag-pki-10.3.5-1.fc25* >> o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f0224b152 >> dogtag-pki-theme-10.3.5-1.fc25* >> o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-0a384ead60 >> pki-core-10.3.5-1.fc25 >> * >> o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-849cbeecb1 >> pki-console-10.3.5-1.fc25 >> * >> o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f6bc9b601 >> ldapjdk-4.18-19.fc25 >> >> * >> >> >> > On Fedora 24 I am unable to upgrade to these packages without manual > intervention: > [root at vm freeipa]# dnf update --allowerasing --best > Last metadata expiration check: 2:08:29 ago on Wed Aug 10 16:38:24 2016. > Error: nothing provides resteasy-atom-provider >= 3.0.17-1 needed by > pki-base-java-10.3.5-1.fc24.noarch. > package pki-tools-10.3.5-1.fc24.x86_64 requires pki-base-java = > 10.3.5-1.fc24, but none of the providers can be installed. > nothing provides resteasy-atom-provider >= 3.0.17-1 needed by > pki-base-java-10.3.5-1.fc24.noarch. > nothing provides resteasy-atom-provider >= 3.0.17-1 needed by > pki-base-java-10.3.5-1.fc24.noarch. > nothing provides resteasy-atom-provider >= 3.0.17-1 needed by > pki-base-java-10.3.5-1.fc24.noarch. > nothing provides resteasy-atom-provider >= 3.0.17-1 needed by > pki-base-java-10.3.5-1.fc24.noarch > [root at vm freeipa]# rpm -q resteasy-atom-provider > resteasy-atom-provider-3.0.6-11.fc24.noarch > > Am I doing something wrong, or does the new resteasy need to be added > back to testing? > (https://bodhi.fedoraproject.org/updates/FEDORA-2016-d80872c309) > > Ben Ben, No, the resteasy 3.0.17 builds received bad karma because they were utilized with an incompatible pki-core 10.3.3 as used by FreeIPA and the packages were thus obsoleted. This build fixes that problem, but requires the version of resteasy 3.0.17 that was obsoleted. We are going to inquire if resteasy 3.0.17 for Fedora 24 can be re-issued to bodhi. If the change is going to be backed out permanently, it would require yet another re-spin of the pki-core bits. Stay tuned, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Aug 11 05:49:16 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Aug 2016 07:49:16 +0200 Subject: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument In-Reply-To: <47ac8912-1caf-bdd8-bb32-fdb29dffffb8@redhat.com> References: <7a64f453-df5a-0691-746c-1b04c7171f8a@redhat.com> <47ac8912-1caf-bdd8-bb32-fdb29dffffb8@redhat.com> Message-ID: <3b23492e-17e7-13e1-1099-16cfb0963c98@redhat.com> On 2.8.2016 13:47, Stanislav Laznicka wrote: > On 07/19/2016 09:20 AM, Jan Cholasta wrote: >> Hi, >> >> On 14.7.2016 14:36, Stanislav Laznicka wrote: >>> Hello, >>> >>> This patch fixes https://fedorahosted.org/freeipa/ticket/5640. >>> >>> With not so much experience with the framework, it raises question in my >>> head whether ipaldap.get_entries is used properly throughout the system >>> - does it always assume that it gets ALL the requested entries or just a >>> few of those as configured by the 'ipaSearchRecordsLimit' attribute of >>> ipaConfig.etc which it actually gets? >> >> That depends. If you call get_entries() on the ldap2 plugin (which is >> usually the case in the framework), then ipaSearchRecordsLimit is >> used. If you call it on some arbitrary LDAPClient instance, the >> hardcoded default (= unlimited) is used. >> >>> >>> One spot that I know the get_entries method was definitely not used >>> properly before this patch is in the >>> baseldap.LDAPObject.get_memberindirect() method: >>> >>> 692 result = self.backend.get_entries( >>> 693 self.api.env.basedn, >>> 694 filter=filter, >>> 695 attrs_list=['member'], >>> 696 size_limit=-1, # paged search will get everything >>> anyway >>> 697 paged_search=True) >>> >>> which to me seems kind of important if the environment size_limit is not >>> set properly :) The patch does not fix the non-propagation of the >>> paged_search, though. >> >> Why do you think size_limit is not used properly here? > AFAIU it is desired that the search is unlimited. However, due to the > fact that neither size_limit nor paged_search are passed from > ldap2.get_entries() to ldap2.find_entries() (methods inherited from > LDAPClient), only the number of records specified by > ipaSearchRecordsLimit is returned. That could eventually cause problems > should ipaSearchRecordsLimit be set to a low value as in the ticket. I see. This is *not* intentional, the **kwargs of get_entries() should be passed to find_entries(). This definitely needs to be fixed. >> >> Anyway, this ticket is not really easily fixable without more profound >> changes. Often, multiple LDAP searches are done during command >> execution. What do you do with the size limit then? Do you pass the >> same size limit to all the searches? Do you subtract the result size >> from the size limit after each search? Do you do something else with >> it? ... The answer is that it depends on the purpose of each >> individual LDAP search (like in get_memberindirect() above, we have to >> do unlimited search, otherwise the resulting entry would be >> incomplete), and fixing this accross the whole framework is a >> non-trivial task. >> > I do realize that the proposed fix for the permission plugin is not > perfect, it would probably be better to subtract the number of currently > loaded records from the sizelimit, although in the end the number of > returned values will not be higher than the given size_limit. However, > it seems reasonable that if get_entries is passed a size limit, it > should apply it over current ipaSearchRecordsLimit rather than ignoring > it. Then, any use of get_entries could be fixed accordingly if someone > sees fit. > Right. Anyway, this is a different issue than above, so please put this into a separate commit. -- Jan Cholasta From ldoudova at redhat.com Thu Aug 11 06:40:57 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 11 Aug 2016 08:40:57 +0200 Subject: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate In-Reply-To: <21609031-d13b-eb27-f945-513d244d18cf@redhat.com> References: <1004948019.9643194.1469705403940.JavaMail.zimbra@redhat.com> <11d0579b-2ca2-af88-ed97-2efa477290c0@redhat.com> <529785673.9646711.1469705707399.JavaMail.zimbra@redhat.com> <47d419bd-2b40-8573-2c65-c22a255f5607@redhat.com> <21609031-d13b-eb27-f945-513d244d18cf@redhat.com> Message-ID: <10819e26-5430-33ef-65b9-3f59c5f8ba9e@redhat.com> On 08/10/2016 05:48 PM, Martin Basti wrote: > > > > On 08.08.2016 10:30, Martin Basti wrote: >> >> >> >> On 02.08.2016 14:50, Lenka Doudova wrote: >>> >>> >>> >>> On 07/29/2016 11:43 AM, Lenka Doudova wrote: >>>> >>>> >>>> >>>> On 07/29/2016 11:41 AM, Lenka Doudova wrote: >>>>> >>>>> On 07/28/2016 01:35 PM, Peter Lacko wrote: >>>>>> Hops, fixed. >>>>>> >>>>>> Peter >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Lenka Doudova" >>>>>> To:freeipa-devel at redhat.com >>>>>> Sent: Thursday, July 28, 2016 1:32:25 PM >>>>>> Subject: Re: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate >>>>>> >>>>>> Hi, >>>>>> >>>>>> I cannot find any attached patch :) >>>>>> >>>>>> Lenka >>>>>> >>>>>> >>>>>> On 07/28/2016 01:30 PM, Peter Lacko wrote: >>>>>>> Attached you can find a patch adding test for URIs in generated certificate >>>>>>> ipatests/test_xmlrpc/test_cert_plugin.py >>>>>>> Since I'm leaving Red Hat in end of July, I won't be able to modify this patch anymore. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Peter >>>>>>> >>>>>> >>>>>> >>>>> Hi, >>>>> >>>>> NACK. Code looks fine and works well on master branch, but patch >>>>> does not apply on 4-3 and 4-2 branches. >>>>> Peter left the company but claimed he can fix the patch if >>>>> necessary, I'll communicate it with him or fix it myself. >>>>> >>>>> Lenka >>>>> >>>>> >>>> Oh, and forgot this one - PEP8 error: >>>> ./ipatests/test_xmlrpc/test_cert_plugin.py:191:80: E501 line too >>>> long (105 > 79 characters) >>>> >>>> Lenka >>>> >>>> >>> Hi, >>> >>> since Peter has quit already, I took it upon myself to do minor fix >>> and rebase to the patch. >>> 1) i removed pylint disable comments from the patch, as they were >>> unnecessary (this also solved PEP8 error) >>> 2) I rebased the patch to be applicable for ipa-4-3 branch. >>> Original functionality of the patch remains unchanged. >>> >>> Both fixed patches attached. >>> >>> Lenka >>> >>> >> >> Hello, >> >> 1) >> This is not needed >> + global sn >> + >> + result = api.Command.cert_show(sn, out=unicode(self.certfile)) >> >> you need the global statement only for write access. But sn is not assigned in this code block. >> >> 2) >> I prefer to use instance attributes (self.sn) instead of global variables > > As we figured out, pytest creates for each test new instance of class, > so 2) will not fork. > Please fix only 1), sorry. > > Martin^2 Hi, attached fixed patches for master and 4.3 branches. Lenka > >> Martin^2 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-placko-0003-3-ipa43-Test-URIs-in-certificate.patch Type: text/x-patch Size: 4768 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-placko-0003-3-Test-URIs-in-certificate.patch Type: text/x-patch Size: 4721 bytes Desc: not available URL: From tdudlak at redhat.com Thu Aug 11 07:55:30 2016 From: tdudlak at redhat.com (Tibor Dudlak) Date: Thu, 11 Aug 2016 09:55:30 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Added support for authentication with user certificate In-Reply-To: References: Message-ID: Hi, I think this patch is finished. If it does not suits you and it will not be merged please consider merging PATCH 0001 from http://www.redhat.com/archives/freeipa-devel/2016-August/msg00009.html at least. Thank you On Wed, Aug 10, 2016 at 10:17 AM, Tibor Dudlak wrote: > Hi, > > I have improved my previous patch for authentication with user > certificate/smartcard. > This patch includes patches and plugin and apache configuration described > here: http://www.freeipa.org/page/V4/External_Authentication/Setup > It also contains steps to configure and test this feature. Once this patch > is merged and released I will simplify this page to not confuse customers. > > On Fri, Aug 5, 2016 at 3:58 PM, Petr Vobornik wrote: > >> On 08/05/2016 02:57 PM, Tibor Dudlak wrote: >> >... >> >> Let's assume that we will go with this approach and not separate RPM. >> >> 1. ipa.conf version needs to be bumped >> > > We have found another problem with ipa.conf approach so I have moved > configuration of apache for plugin from ipa.conf into completely separated > file to be not configured in FreeIPA by default. As you said it may cause > some security issues and it definitely causes errors when plugin > dependences are not installed nor configured. > > 2. Do not put the web ui plugin in src/freeipa/plugins dir. That is a >> dir for core UI plugins. This one is sort of hybrid - basically a third >> party plugin added to core package but enabled as third party because >> the feature is experimental. >> >> Create rather a new dir for that. E.g. plugins.d as Alexander suggested >> -> freeipa/install/ui/src/plugins.d/cert_auth/cert_auth.js >> >> 3. unrelated and "alternative solution" comments needs to be removed >> from the UI plugin. They were added to the example plugin >> https://pvoborni.fedorapeople.org/plugins/loginauth/loginauth.js mostly >> to help you with the development. >> >> 4. Add comment to freeipa.spec.in describing what the plugin is and why >> it is put there this way. >> >> 5. The plugin itself deserves better description as well. Right now >> there is the general description. >> >> 6. I have not tried it, but make sure that it passes jslint (`jsl -conf >> jsl.conf`) Easiest may be to use temp(i.e. do not include it here) >> jsl.conf e.g.: https://pvoborni.fedorapeople. >> org/plugins/loginauth/jsl.conf >> >> -- >> Petr Vobornik >> > > I hope result of jsl http://pastebin.test.redhat.com/400076 means that > things passed. > Thanks Petr for review and I hope this patch will cover all concerns he > had. > > Addressing ticket: https://fedorahosted.org/freeipa/ticket/5764 > > Thank you. > > -- > Tibor Dudl?k > Intern - Identity management Special Projects > Red Hat > -- Tibor Dudl?k Intern - Identity management Special Projects Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Aug 11 08:05:32 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 10:05:32 +0200 Subject: [Freeipa-devel] [Test][patch-0058] Fixed topology tests failures in CI In-Reply-To: <57AB735A.3000101@redhat.com> References: <57AB735A.3000101@redhat.com> Message-ID: On 10.08.2016 20:32, Oleg Fayans wrote: > > > Hello, before we jump into fixing tests, my question is: Was this planned change and not reflected by test, or switched values are unwanted side effect and thus bug for us? Ticket contains almost no info, except a traceback and it says nothing. Commit message says at least something. I'm not sure if this patch fixes that ticket, because traceback in test shows error message that "removal of segment will disconnect topology", but this patch only swap order of replica names in segment name. I would expect that you should get different error, something like segment does not exist. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Aug 11 08:44:21 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Aug 2016 10:44:21 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <20160804152755.GA4601@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> Message-ID: <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> On 4.8.2016 17:27, Jan Pazdziora wrote: > On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >> >> Got it. One thing I would correct, though, -- don't use kadmin.local, we >> do support setting ok_as_delegate on the service principals via IPA CLI: >> $ ipa service-mod --help |grep -A1 ok-as-delegate >> --ok-as-delegate=BOOL >> Client credentials may be delegated to the service > > I've tried > > ipa service-mod --ok-as-delegate=True HTTP/$(hostname) > > but that does not seem to have the same effect as > > modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test > > -- obtaining the delegated certificated fails. That's because ok_as_delegate and ok_to_auth_as_delegate are different flags. -- Jan Cholasta From abokovoy at redhat.com Thu Aug 11 08:54:48 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Aug 2016 11:54:48 +0300 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> Message-ID: <20160811085448.7dvj2btquzi4276s@redhat.com> On Thu, 11 Aug 2016, Jan Cholasta wrote: >On 4.8.2016 17:27, Jan Pazdziora wrote: >>On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >>> >>>Got it. One thing I would correct, though, -- don't use kadmin.local, we >>>do support setting ok_as_delegate on the service principals via IPA CLI: >>>$ ipa service-mod --help |grep -A1 ok-as-delegate >>> --ok-as-delegate=BOOL >>> Client credentials may be delegated to the service >> >>I've tried >> >> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >> >>but that does not seem to have the same effect as >> >> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >> >>-- obtaining the delegated certificated fails. > >That's because ok_as_delegate and ok_to_auth_as_delegate are different >flags. Right. The following patch adds ok_to_auth_as_delegate to the service principal. I haven't added any tickets to it yet. -- / Alexander Bokovoy -------------- next part -------------- From 9af1c479cf8d1862c001fccd5345bd93dd6e54a8 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 11 Aug 2016 11:52:05 +0300 Subject: [PATCH 6/6] service: add flag to allow S4U2Self --- API.txt | 12 ++++++++---- ipaserver/plugins/service.py | 7 +++++++ 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/API.txt b/API.txt index 535d8ec..5b83bfb 100644 --- a/API.txt +++ b/API.txt @@ -2260,7 +2260,7 @@ output: Output('summary', type=[, ]) output: Output('value', type=[]) output: Output('warning', type=[, , ]) command: host_add/1 -args: 1,24,3 +args: 1,25,3 arg: Str('fqdn', cli_name='hostname') option: Str('addattr*', cli_name='addattr') option: Flag('all', autofill=True, cli_name='all', default=False) @@ -2269,6 +2269,7 @@ option: Flag('force', autofill=True, default=False) option: Str('ip_address?') option: Str('ipaassignedidview?') option: Bool('ipakrbokasdelegate?', cli_name='ok_as_delegate') +option: Bool('ipakrboktoauthasdelegate?', cli_name='ok_to_auth_as_delegate') option: Bool('ipakrbrequirespreauth?', cli_name='requires_pre_auth') option: Str('ipasshpubkey*', cli_name='sshpubkey') option: Str('krbprincipalauthind*', cli_name='auth_ind') @@ -2437,7 +2438,7 @@ output: ListOfEntries('result') output: Output('summary', type=[, ]) output: Output('truncated', type=[]) command: host_mod/1 -args: 1,25,3 +args: 1,26,3 arg: Str('fqdn', cli_name='hostname') option: Str('addattr*', cli_name='addattr') option: Flag('all', autofill=True, cli_name='all', default=False) @@ -2445,6 +2446,7 @@ option: Str('delattr*', cli_name='delattr') option: Str('description?', autofill=False, cli_name='desc') option: Str('ipaassignedidview?', autofill=False) option: Bool('ipakrbokasdelegate?', autofill=False, cli_name='ok_as_delegate') +option: Bool('ipakrboktoauthasdelegate?', autofill=False, cli_name='ok_to_auth_as_delegate') option: Bool('ipakrbrequirespreauth?', autofill=False, cli_name='requires_pre_auth') option: Str('ipasshpubkey*', autofill=False, cli_name='sshpubkey') option: Str('krbprincipalauthind*', autofill=False, cli_name='auth_ind') @@ -4293,13 +4295,14 @@ output: Entry('result') output: Output('summary', type=[, ]) output: PrimaryKey('value') command: service_add/1 -args: 1,12,3 +args: 1,13,3 arg: Principal('krbcanonicalname', cli_name='canonical_principal') option: Str('addattr*', cli_name='addattr') option: Flag('all', autofill=True, cli_name='all', default=False) option: Flag('force', autofill=True, default=False) option: StrEnum('ipakrbauthzdata*', cli_name='pac_type', values=[u'MS-PAC', u'PAD', u'NONE']) option: Bool('ipakrbokasdelegate?', cli_name='ok_as_delegate') +option: Bool('ipakrboktoauthasdelegate?', cli_name='ok_to_auth_as_delegate') option: Bool('ipakrbrequirespreauth?', cli_name='requires_pre_auth') option: Str('krbprincipalauthind*', cli_name='auth_ind') option: Flag('no_members', autofill=True, default=False) @@ -4435,13 +4438,14 @@ output: ListOfEntries('result') output: Output('summary', type=[, ]) output: Output('truncated', type=[]) command: service_mod/1 -args: 1,14,3 +args: 1,15,3 arg: Principal('krbcanonicalname', cli_name='canonical_principal') option: Str('addattr*', cli_name='addattr') option: Flag('all', autofill=True, cli_name='all', default=False) option: Str('delattr*', cli_name='delattr') option: StrEnum('ipakrbauthzdata*', autofill=False, cli_name='pac_type', values=[u'MS-PAC', u'PAD', u'NONE']) option: Bool('ipakrbokasdelegate?', autofill=False, cli_name='ok_as_delegate') +option: Bool('ipakrboktoauthasdelegate?', autofill=False, cli_name='ok_to_auth_as_delegate') option: Bool('ipakrbrequirespreauth?', autofill=False, cli_name='requires_pre_auth') option: Str('krbprincipalauthind*', autofill=False, cli_name='auth_ind') option: Principal('krbprincipalname*', autofill=False, cli_name='principal') diff --git a/ipaserver/plugins/service.py b/ipaserver/plugins/service.py index a44dcaa..04d1916 100644 --- a/ipaserver/plugins/service.py +++ b/ipaserver/plugins/service.py @@ -171,11 +171,18 @@ ticket_flags_params = ( doc=_('Client credentials may be delegated to the service'), flags=['virtual_attribute', 'no_search'], ), + Bool('ipakrboktoauthasdelegate?', + cli_name='ok_to_auth_as_delegate', + label=_('Trusted to authenticate as user'), + doc=_('The service is allowed to authenticate on behalf of a client'), + flags=['virtual_attribute', 'no_search'], + ), ) _ticket_flags_map = { 'ipakrbrequirespreauth': 0x00000080, 'ipakrbokasdelegate': 0x00100000, + 'ipakrboktoauthasdelegate': 0x00200000, } _ticket_flags_default = _ticket_flags_map['ipakrbrequirespreauth'] -- 2.7.4 From mbasti at redhat.com Thu Aug 11 09:00:21 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 11:00:21 +0200 Subject: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts In-Reply-To: <256010841.13930537.1470754537126.JavaMail.zimbra@redhat.com> References: <256010841.13930537.1470754537126.JavaMail.zimbra@redhat.com> Message-ID: On 09.08.2016 16:55, Ganna Kaihorodova wrote: > Hello! > > Domain level 0 doesn't allow to create replica file on CA master, testcase was skipped with Domain level 0 > > https://fedorahosted.org/freeipa/ticket/6134 > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > > Hello, Please fix PEP8 error you introduced. ./ipatests/test_integration/test_replication_layouts.py:32:1: E302 expected 2 blank lines, found 1 IMO this need skip on domain level 0 too * Test2ConnectedTopologyWithoutCA * TestDoubleCircleTopologyWithoutCA Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Aug 11 09:52:52 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Aug 2016 11:52:52 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Added support for authentication with user certificate In-Reply-To: References: Message-ID: Hi, On 11.8.2016 09:55, Tibor Dudlak wrote: > Hi, > > I think this patch is finished. If it does not suits you and it will not > be merged please consider merging PATCH 0001 from > http://www.redhat.com/archives/freeipa-devel/2016-August/msg00009.html > at least. > > Thank you > > On Wed, Aug 10, 2016 at 10:17 AM, Tibor Dudlak > wrote: > > Hi, > > I have improved my previous patch for authentication with user > certificate/smartcard. > This patch includes patches and plugin and apache configuration > described here: > http://www.freeipa.org/page/V4/External_Authentication/Setup > > It also contains steps to configure and test this feature. Once this > patch is merged and released I will simplify this page to not > confuse customers. > > On Fri, Aug 5, 2016 at 3:58 PM, Petr Vobornik > wrote: > > On 08/05/2016 02:57 PM, Tibor Dudlak wrote: > >... > > Let's assume that we will go with this approach and not separate > RPM. > > 1. ipa.conf version needs to be bumped > > > We have found another problem with ipa.conf approach so I have moved > configuration of apache for plugin from ipa.conf into completely > separated file to be not configured in FreeIPA by default. As you > said it may cause some security issues and it definitely causes > errors when plugin dependences are not installed nor configured. > > 2. Do not put the web ui plugin in src/freeipa/plugins dir. That > is a > dir for core UI plugins. This one is sort of hybrid - basically > a third > party plugin added to core package but enabled as third party > because > the feature is experimental. > > Create rather a new dir for that. E.g. plugins.d as Alexander > suggested > -> freeipa/install/ui/src/plugins.d/cert_auth/cert_auth.js > > 3. unrelated and "alternative solution" comments needs to be > removed > from the UI plugin. They were added to the example plugin > https://pvoborni.fedorapeople.org/plugins/loginauth/loginauth.js > > mostly > to help you with the development. > > 4. Add comment to freeipa.spec.in > describing what the plugin is and why > it is put there this way. > > 5. The plugin itself deserves better description as well. Right now > there is the general description. > > 6. I have not tried it, but make sure that it passes jslint > (`jsl -conf > jsl.conf`) Easiest may be to use temp(i.e. do not include it here) > jsl.conf e.g.: > https://pvoborni.fedorapeople.org/plugins/loginauth/jsl.conf > > > -- > Petr Vobornik > > > I hope result of jsl http://pastebin.test.redhat.com/400076 > means that things passed. > Thanks Petr for review and I hope this patch will cover all concerns > he had. > > Addressing ticket: https://fedorahosted.org/freeipa/ticket/5764 > > > Thank you. +class login_x509(login_kerberos, KerberosSession, HTTP_Status): + key = '/session/login_x509' login_kerberos already subclasses KerberosSession and HTTP_Status, no need to do it again here. In fact, it would be best to split off the bussiness logic from login_kerberos into a separate class and inherit both login_kerberos and login_x509 from it: class KerberosLogin(Backend, KerberosSession, HTTP_Status): def _on_finalize(self): ... def __call__(self, ...): ... class login_kerberos(KerberosLogin): key = '/session/login_kerberos' class login_x509(KerberosLogin): key = '/session/login_x509' Honza -- Jan Cholasta From slaznick at redhat.com Thu Aug 11 10:34:56 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 11 Aug 2016 12:34:56 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies Message-ID: Hello, I updated the design of the Time-Based HBAC Policies according to the discussion we led here earlier. Please check the design page http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest changes are in the Implementation and Feature Management sections. I also added a short How to Use section. On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI functionality (except for the creation of iCalendar strings from options) for better illustration of the design. https://github.com/stlaz/freeipa/tree/timerules_2 I will add FreeIPA people that recently had some say about this to CC so that we can get the discussion flowing. Thanks, Standa From pvoborni at redhat.com Thu Aug 11 12:00:25 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 11 Aug 2016 14:00:25 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <20160811085448.7dvj2btquzi4276s@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> Message-ID: <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: > On Thu, 11 Aug 2016, Jan Cholasta wrote: >> On 4.8.2016 17:27, Jan Pazdziora wrote: >>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >>>> >>>> Got it. One thing I would correct, though, -- don't use >>>> kadmin.local, we >>>> do support setting ok_as_delegate on the service principals via IPA >>>> CLI: >>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>>> --ok-as-delegate=BOOL >>>> Client credentials may be delegated to the >>>> service >>> >>> I've tried >>> >>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >>> >>> but that does not seem to have the same effect as >>> >>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >>> >>> -- obtaining the delegated certificated fails. >> >> That's because ok_as_delegate and ok_to_auth_as_delegate are different >> flags. > Right. The following patch adds ok_to_auth_as_delegate to the service > principal. > > I haven't added any tickets to it yet. > > This might deserve also nice Web UI checkbox similar to "Trusted for delegation". CCing Pavel. -- Petr Vobornik From mbasti at redhat.com Thu Aug 11 12:27:21 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 14:27:21 +0200 Subject: [Freeipa-devel] [PATCHES 681-682] cert: speed up cert-find, do not crash on invalid data in cert-find In-Reply-To: <5fdd4314-7c3f-242d-1648-0aae521f1743@redhat.com> References: <5fdd4314-7c3f-242d-1648-0aae521f1743@redhat.com> Message-ID: <35ddad7d-664a-1231-c8ae-afd4d4b43443@redhat.com> On 01.08.2016 10:27, Jan Cholasta wrote: > On 1.8.2016 10:19, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix >> and . > > Self-NACK, proper patches attached. > > Honza > > > IMHO this is caused by your patches, test_cert_plugin.py: [Thu Aug 11 14:12:18.740950 2016] [wsgi:error] [pid 85941] ipa: ERROR: non-public: KeyError: 'owner' [Thu Aug 11 14:12:18.740986 2016] [wsgi:error] [pid 85941] Traceback (most recent call last): [Thu Aug 11 14:12:18.740988 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 359, in wsgi_execute [Thu Aug 11 14:12:18.740990 2016] [wsgi:error] [pid 85941] result = self.Command[name](*args, **options) [Thu Aug 11 14:12:18.740992 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ [Thu Aug 11 14:12:18.740994 2016] [wsgi:error] [pid 85941] return self.__do_call(*args, **options) [Thu Aug 11 14:12:18.740995 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call [Thu Aug 11 14:12:18.740997 2016] [wsgi:error] [pid 85941] ret = self.run(*args, **options) [Thu Aug 11 14:12:18.740998 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run [Thu Aug 11 14:12:18.741000 2016] [wsgi:error] [pid 85941] return self.execute(*args, **options) [Thu Aug 11 14:12:18.741001 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line 1571, in execute [Thu Aug 11 14:12:18.741003 2016] [wsgi:error] [pid 85941] delete_entry(pkey) [Thu Aug 11 14:12:18.741004 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line 1524, in delete_entry [Thu Aug 11 14:12:18.741014 2016] [wsgi:error] [pid 85941] dn = callback(self, ldap, dn, *nkeys, **options) [Thu Aug 11 14:12:18.741016 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/host.py", line 794, in pre_callback [Thu Aug 11 14:12:18.741018 2016] [wsgi:error] [pid 85941] api.Command['service_del'](principal) [Thu Aug 11 14:12:18.741019 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ [Thu Aug 11 14:12:18.741021 2016] [wsgi:error] [pid 85941] return self.__do_call(*args, **options) [Thu Aug 11 14:12:18.741022 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call [Thu Aug 11 14:12:18.741024 2016] [wsgi:error] [pid 85941] ret = self.run(*args, **options) [Thu Aug 11 14:12:18.741025 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run [Thu Aug 11 14:12:18.741027 2016] [wsgi:error] [pid 85941] return self.execute(*args, **options) [Thu Aug 11 14:12:18.741028 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line 1571, in execute [Thu Aug 11 14:12:18.741029 2016] [wsgi:error] [pid 85941] delete_entry(pkey) [Thu Aug 11 14:12:18.741031 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line 1524, in delete_entry [Thu Aug 11 14:12:18.741032 2016] [wsgi:error] [pid 85941] dn = callback(self, ldap, dn, *nkeys, **options) [Thu Aug 11 14:12:18.741034 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/service.py", line 674, in pre_callback [Thu Aug 11 14:12:18.741035 2016] [wsgi:error] [pid 85941] revoke_certs(entry_attrs.get('usercertificate', []), self.log) [Thu Aug 11 14:12:18.741037 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/service.py", line 230, in revoke_certs [Thu Aug 11 14:12:18.741038 2016] [wsgi:error] [pid 85941] result = api.Command['cert_show'](unicode(serial))['result'] [Thu Aug 11 14:12:18.741040 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ [Thu Aug 11 14:12:18.741041 2016] [wsgi:error] [pid 85941] return self.__do_call(*args, **options) [Thu Aug 11 14:12:18.741042 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call [Thu Aug 11 14:12:18.741044 2016] [wsgi:error] [pid 85941] ret = self.run(*args, **options) [Thu Aug 11 14:12:18.741045 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run [Thu Aug 11 14:12:18.741047 2016] [wsgi:error] [pid 85941] return self.execute(*args, **options) [Thu Aug 11 14:12:18.741048 2016] [wsgi:error] [pid 85941] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 792, in execute [Thu Aug 11 14:12:18.741050 2016] [wsgi:error] [pid 85941] del result['owner'] [Thu Aug 11 14:12:18.741051 2016] [wsgi:error] [pid 85941] KeyError: 'owner' -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Aug 11 12:51:11 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 14:51:11 +0200 Subject: [Freeipa-devel] [PATCHES] Coverity fixes In-Reply-To: <20160805121337.GG6891@10.4.128.1> References: <1469440019.18067.66.camel@redhat.com> <6dcfcd32-05e3-d36c-484a-bb074373af4c@redhat.com> <20160805121337.GG6891@10.4.128.1> Message-ID: <1ce4148c-8b9e-88c9-e612-6b64a0f697f6@redhat.com> On 05.08.2016 14:13, Lukas Slebodnik wrote: > On (05/08/16 12:43), Petr Vobornik wrote: >> On 07/28/2016 01:01 PM, Martin Basti wrote: >>> >>> On 25.07.2016 11:46, Simo Sorce wrote: >>>> The attached patches fix some minor issues found by coverity, and pull >>>> in other fixes released by the asn1c project. >>>> >>>> Simo. >>>> >>>> >>>> >>> I cannot build RPMS with this patch, is there any missing build dependency? >>> >>> /bin/sh ./libtool --tag=CC --mode=link gcc -Wall -Wshadow >>> -Wstrict-prototypes -Wpointer-arith -Wcast-align >>> -Werror-implicit-function-declaration -O2 -g -pipe -Wall >>> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall >>> -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare >>> -Wno-missing-field-initializers -Wl,-z,relro >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o >>> ipa-client-common.o ipa_krb5.o ../asn1/libipaasn1.la -lkrb5 -lk5crypto -lcom_err >>> -llber -lldap -lsasl2 -lpopt -lini_config -lbasicobjects -lref_array >>> -lcollection -lini_config -lini_config >>> libtool: link: gcc -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith >>> -Wcast-align -Werror-implicit-function-declaration -O2 -g -pipe -Wall >>> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall >>> -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare >>> -Wno-missing-field-initializers -Wl,-z -Wl,relro >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o >>> ipa-client-common.o ipa_krb5.o ../asn1/.libs/libipaasn1.a -lkrb5 -lk5crypto >>> -lcom_err -llber -lldap -lsasl2 -lpopt -lbasicobjects -lref_array -lcollection >>> -lini_config >>> ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_decode_uper': >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:897: >>> undefined reference to `uper_open_type_get' >>> ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_encode_uper': >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:982: >>> undefined reference to `uper_open_type_put' >>> ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function >>> `SEQUENCE_handle_extensions': >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1285: >>> undefined reference to `uper_open_type_put' >>> ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function `SEQUENCE_decode_uper': >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1187: >>> undefined reference to `uper_open_type_get' >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1203: >>> undefined reference to `uper_open_type_skip' >>> collect2: error: ld returned 1 exit status >>> >>> Martin^2 >>> >> Bumping. Was it temporary issue or issue in the patch? >> > I could not see such error. > However, these patches would be good to test with coverity. > We need to use fedora rawhide for testing due to BuildRequires > in freeipa.spec. But C-part of freeIPA cannot be compiled on rawhide > due to new samba (4.5). Patches are already on the list. > > LS > Lukas helped me to fix error I reported before (missing entries in Makefile.am), so I run covscan and I get bunch of new errors. Question is, do we want push autogenerated code? Error: FORWARD_NULL (CWE-476): [#def1] freeipa-4.4.0/asn1/asn1c/INTEGER.c:463: assign_zero: Assigning: "dec_value_start" = "NULL". freeipa-4.4.0/asn1/asn1c/INTEGER.c:488: var_deref_model: Passing null pointer "dec_value_start" to "asn_strtol_lim", which dereferences it. freeipa-4.4.0/asn1/asn1c/INTEGER.c:975:2: deref_parm: Directly dereferencing parameter "str". # 973| if(str >= *end) return ASN_STRTOL_ERROR_INVAL; # 974| # 975|-> switch(*str) { # 976| case '-': # 977| last_digit_max++; Error: MISSING_BREAK (CWE-484): [#def2] freeipa-4.4.0/asn1/asn1c/INTEGER.c:976: unterminated_case: The case for value "'-'" is not terminated by a 'break' statement. freeipa-4.4.0/asn1/asn1c/INTEGER.c:979: fallthrough: The above case falls through to this one. # 977| last_digit_max++; # 978| sign = -1; # 979|-> case '+': # 980| str++; # 981| if(str >= *end) { Error: NEGATIVE_RETURNS (CWE-394): [#def3] freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:381: var_tested_neg: Variable "tlv_len" tests negative. freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:391: var_assign: Assigning: signed variable "sel->left" = "tlv_len". freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:247: var_assign: Assigning: unsigned variable "Left" = "sel->left". freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:275: negative_returns: "Left" is passed to a parameter that cannot be negative. freeipa-4.4.0/asn1/asn1c/ber_tlv_tag.c:33:2: parm_loop_bound: Using unsigned parameter "size" in a loop exit test. # 273| } # 274| # 275|-> tl = ber_fetch_tag(buf_ptr, Left, &tlv_tag); # 276| ASN_DEBUG("fetch tag(size=%ld,L=%ld), %sstack, left=%ld, wn=%ld, tl=%ld", # 277| (long)size, (long)Left, sel?"":"!", Error: FORWARD_NULL (CWE-476): [#def4] freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:583: var_compare_op: Comparing "st->buf" to null implies that "st->buf" might be null. freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:591: alias_transfer: Assigning: "buf" = "st->buf". freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:601: var_deref_op: Dereferencing null pointer "buf". # 599| p = scratch; # 600| } # 601|-> *p++ = h2c[(*buf >> 4) & 0x0F]; # 602| *p++ = h2c[*buf & 0x0F]; # 603| } Error: FORWARD_NULL (CWE-476): [#def5] freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:583: var_compare_op: Comparing "st->buf" to null implies that "st->buf" might be null. freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:591: alias_transfer: Assigning: "buf" = "st->buf". freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:615: var_deref_op: Dereferencing null pointer "buf". # 613| _i_ASN_TEXT_INDENT(1, ilevel); # 614| } # 615|-> *p++ = h2c[(*buf >> 4) & 0x0F]; # 616| *p++ = h2c[*buf & 0x0F]; # 617| *p++ = 0x20; Error: FORWARD_NULL (CWE-476): [#def6] freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:739: var_compare_op: Comparing "st->buf" to null implies that "st->buf" might be null. freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:742: alias_transfer: Assigning: "buf" = "st->buf". freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:745: var_deref_op: Dereferencing null pointer "buf". # 743| end = buf + st->size; # 744| for(ss = buf; buf < end; buf++) { # 745|-> unsigned int ch = *buf; # 746| int s_len; /* Special encoding sequence length */ # 747| Error: FORWARD_NULL (CWE-476): [#def7] freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1659: var_compare_op: Comparing "st->buf" to null implies that "st->buf" might be null. freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1665: alias_transfer: Assigning: "buf" = "st->buf". freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1674: var_deref_op: Dereferencing null pointer "buf". # 1672| p = scratch; # 1673| } # 1674|-> *p++ = h2c[(*buf >> 4) & 0x0F]; # 1675| *p++ = h2c[*buf & 0x0F]; # 1676| *p++ = 0x20; Error: REVERSE_INULL (CWE-476): [#def8] freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1706: deref_ptr: Directly dereferencing pointer "td". freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1713: check_after_deref: Null-checking "td" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. # 1711| struct _stack *stck; # 1712| # 1713|-> if(!td || !st) # 1714| return; # 1715| Error: DEADCODE (CWE-561): [#def9] freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:40: assignment: Assigning: "len" = "0L". freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:44: cond_at_least: Condition "len < 0L", taking false branch. Now the value of "len" is at least 0. freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:54: assignment: Assigning: "lenplusepsilon" = "(size_t)len + 1024UL". freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:63: at_least: At condition "lenplusepsilon < 0L", the value of "lenplusepsilon" must be at least 1024. freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:63: dead_error_condition: The condition "lenplusepsilon < 0L" cannot be true. freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:65: dead_error_line: Execution cannot reach this statement: "return -1L;". # 63| if(lenplusepsilon < 0) { # 64| /* Too large length value */ # 65|-> return -1; # 66| } # 67| Error: REVERSE_INULL (CWE-476): [#def10] freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:1034: deref_ptr: Directly dereferencing pointer "td". freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:1037: check_after_deref: Null-checking "td" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. # 1035| int present; # 1036| # 1037|-> if(!td || !ptr) # 1038| return; # 1039| Error: RESOURCE_LEAK (CWE-772): [#def11] freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1147: alloc_fn: Storage is returned from allocation function "malloc". freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1147: var_assign: Assigning: "epres" = storage returned from "malloc(bmlength + 15L >> 3)". freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1151: noescape: Resource "epres" is not freed or pointed-to in "per_get_many_bits". freeipa-4.4.0/asn1/asn1c/per_support.c:123:48: noescape: "per_get_many_bits(asn_per_data_t *, uint8_t *, int, int)" does not free or save its parameter "dst". freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1152: leaked_storage: Variable "epres" going out of scope leaks the storage it points to. # 1150| /* Get the extensions map */ # 1151| if(per_get_many_bits(pd, epres, 0, bmlength)) # 1152|-> _ASN_DECODE_STARVED; # 1153| # 1154| memset(&epmd, 0, sizeof(epmd)); Error: CHECKED_RETURN (CWE-252): [#def12] freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1320: check_return: Calling "per_put_few_bits" without checking return value (as is done elsewhere 23 out of 28 times). freeipa-4.4.0/asn1/asn1c/INTEGER.c:724: example_checked: Example 1: "per_put_few_bits(po, inext, 1)" has its value checked in "per_put_few_bits(po, inext, 1)". freeipa-4.4.0/asn1/asn1c/NativeEnumerated.c:180: example_checked: Example 2: "per_put_few_bits(po, inext, 1)" has its value checked in "per_put_few_bits(po, inext, 1)". freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1307: example_checked: Example 3: "per_put_few_bits(po, ch, unit_bits)" has its value checked in "per_put_few_bits(po, ch, unit_bits)". freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:949: example_checked: Example 4: "per_put_few_bits(po, 1U, 1)" has its value checked in "per_put_few_bits(po, 1U, 1)". freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1282: example_checked: Example 5: "per_put_few_bits(po1, present, 1)" has its value checked in "per_put_few_bits(po1, present, 1)". # 1318| if(specs->ext_before >= 0) { # 1319| n_extensions = SEQUENCE_handle_extensions(td, sptr, 0, 0); # 1320|-> per_put_few_bits(po, n_extensions ? 1 : 0, 1); # 1321| } else { # 1322| n_extensions = 0; /* There are no extensions to encode */ Error: DEADCODE (CWE-561): [#def13] freeipa-4.4.0/asn1/asn1c/per_encoder.c:126: cond_notnull: Condition "td", taking true branch. Now the value of "td" is not "NULL". freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: notnull: At condition "td", the value of "td" cannot be "NULL". freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: dead_error_condition: The condition "td" must be true. freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: dead_error_line: Execution cannot reach the expression """" inside this statement: "ASN_DEBUG("Failed to encode...". # 144| # 145| if(_uper_encode_flush_outp(&po)) # 146|-> _ASN_ENCODE_FAILED; # 147| } # 148| Error: DEADCODE (CWE-561): [#def14] freeipa-4.4.0/asn1/asn1c/per_opentype.c:176: assignment: Assigning: "padding" = "pd->moved % 8UL". freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: between: At condition "padding > 7L", the value of "padding" must be between 1 and 7. freeipa-4.4.0/asn1/asn1c/per_opentype.c:177: cond_cannot_single: Condition "padding", taking true branch. Now the value of "padding" cannot be equal to 0. freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: cannot_single: At condition "padding > 7L", the value of "padding" cannot be equal to 0. freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: dead_error_condition: The condition "padding > 7L" cannot be true. freeipa-4.4.0/asn1/asn1c/per_opentype.c:180: dead_error_begin: Execution cannot reach this statement: "ASN_DEBUG("Too large paddin...". # 178| int32_t pvalue; # 179| if(padding > 7) { # 180|-> ASN_DEBUG("Too large padding %d in open type", # 181| (int)padding); # 182| rv.code = RC_FAIL; Error: OVERRUN (CWE-119): [#def15] freeipa-4.4.0/asn1/asn1c/per_support.c:14: assignment: Assigning: "n" = "(n + 1) % 2". The value of "n" is now between 0 and 1 (inclusive). freeipa-4.4.0/asn1/asn1c/per_support.c:15: overrun-buffer-arg: Calling "snprintf" with "buf[n]" and "64UL" is suspicious because the function call may access "buf" at byte "n * sizeof (char [32]) + 63UL". [Note: The source code implementation of the function has been overridden by a builtin model.] # 13| static int n; # 14| n = (n+1) % 2; # 15|-> snprintf(buf[n], sizeof(buf), # 16| "{m=%ld span %+ld[%d..%d] (%d)}", # 17| (long)pd->moved, Error: FORWARD_NULL (CWE-476): [#def16] freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1513: var_compare_op: Comparing "st->buf" to null implies that "st->buf" might be null. freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1618: alias_transfer: Assigning: "buf" = "st->buf". freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1631: var_deref_model: Passing null pointer "buf" to "per_put_many_bits", which dereferences it. freeipa-4.4.0/asn1/asn1c/per_support.c:419:4: deref_parm: Directly dereferencing parameter "src". # 417| # 418| if(nbits >= 24) { # 419|-> value = (src[0] << 16) | (src[1] << 8) | src[2]; # 420| src += 3; # 421| nbits -= 24; From slaznick at redhat.com Thu Aug 11 12:59:05 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 11 Aug 2016 14:59:05 +0200 Subject: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument In-Reply-To: <3b23492e-17e7-13e1-1099-16cfb0963c98@redhat.com> References: <7a64f453-df5a-0691-746c-1b04c7171f8a@redhat.com> <47ac8912-1caf-bdd8-bb32-fdb29dffffb8@redhat.com> <3b23492e-17e7-13e1-1099-16cfb0963c98@redhat.com> Message-ID: On 08/11/2016 07:49 AM, Jan Cholasta wrote: > On 2.8.2016 13:47, Stanislav Laznicka wrote: >> On 07/19/2016 09:20 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 14.7.2016 14:36, Stanislav Laznicka wrote: >>>> Hello, >>>> >>>> This patch fixes https://fedorahosted.org/freeipa/ticket/5640. >>>> >>>> With not so much experience with the framework, it raises question >>>> in my >>>> head whether ipaldap.get_entries is used properly throughout the >>>> system >>>> - does it always assume that it gets ALL the requested entries or >>>> just a >>>> few of those as configured by the 'ipaSearchRecordsLimit' attribute of >>>> ipaConfig.etc which it actually gets? >>> >>> That depends. If you call get_entries() on the ldap2 plugin (which is >>> usually the case in the framework), then ipaSearchRecordsLimit is >>> used. If you call it on some arbitrary LDAPClient instance, the >>> hardcoded default (= unlimited) is used. >>> >>>> >>>> One spot that I know the get_entries method was definitely not used >>>> properly before this patch is in the >>>> baseldap.LDAPObject.get_memberindirect() method: >>>> >>>> 692 result = self.backend.get_entries( >>>> 693 self.api.env.basedn, >>>> 694 filter=filter, >>>> 695 attrs_list=['member'], >>>> 696 size_limit=-1, # paged search will get everything >>>> anyway >>>> 697 paged_search=True) >>>> >>>> which to me seems kind of important if the environment size_limit >>>> is not >>>> set properly :) The patch does not fix the non-propagation of the >>>> paged_search, though. >>> >>> Why do you think size_limit is not used properly here? >> AFAIU it is desired that the search is unlimited. However, due to the >> fact that neither size_limit nor paged_search are passed from >> ldap2.get_entries() to ldap2.find_entries() (methods inherited from >> LDAPClient), only the number of records specified by >> ipaSearchRecordsLimit is returned. That could eventually cause problems >> should ipaSearchRecordsLimit be set to a low value as in the ticket. > > I see. This is *not* intentional, the **kwargs of get_entries() should > be passed to find_entries(). This definitely needs to be fixed. > >>> >>> Anyway, this ticket is not really easily fixable without more profound >>> changes. Often, multiple LDAP searches are done during command >>> execution. What do you do with the size limit then? Do you pass the >>> same size limit to all the searches? Do you subtract the result size >>> from the size limit after each search? Do you do something else with >>> it? ... The answer is that it depends on the purpose of each >>> individual LDAP search (like in get_memberindirect() above, we have to >>> do unlimited search, otherwise the resulting entry would be >>> incomplete), and fixing this accross the whole framework is a >>> non-trivial task. >>> >> I do realize that the proposed fix for the permission plugin is not >> perfect, it would probably be better to subtract the number of currently >> loaded records from the sizelimit, although in the end the number of >> returned values will not be higher than the given size_limit. However, >> it seems reasonable that if get_entries is passed a size limit, it >> should apply it over current ipaSearchRecordsLimit rather than ignoring >> it. Then, any use of get_entries could be fixed accordingly if someone >> sees fit. >> > > Right. Anyway, this is a different issue than above, so please put > this into a separate commit. > Please see the attached patches, then. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0058-2-Make-get_entries-not-ignore-its-limit-arguments.patch Type: text/x-patch Size: 1772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0062-fix-permission_find-fail-on-low-search-size-limit.patch Type: text/x-patch Size: 1831 bytes Desc: not available URL: From pspacek at redhat.com Thu Aug 11 13:08:34 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Aug 2016 15:08:34 +0200 Subject: [Freeipa-devel] [PATCH 0155] DNS server upgrade: do not fail when DNS server did not respond Message-ID: <44f963a2-5e4d-2d34-4e6d-b9b58d6c6f5e@redhat.com> Hello, DNS server upgrade: do not fail when DNS server did not respond Previously, update_dnsforward_emptyzones failed with an exeception if DNS query failed for some reason. Now the error is logged and upgrade continues. I assume that this is okay because the DNS query is used as heuristics of last resort in the upgrade logic and failure to do so should not have catastrophics consequences: In the worst case, the admin needs to manually change forwarding policy from 'first' to 'only'. In the end I have decided not to auto-start BIND because BIND depends on GSSAPI for authentication, which in turn depends on KDC ... Alternative like reconfiguring BIND to use LDAPI+EXTERNAL and reconfiguring DS to accept LDAP external bind from named user are too complicated. https://fedorahosted.org/freeipa/ticket/6205 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0155-DNS-server-upgrade-do-not-fail-when-DNS-server-did-n.patch Type: text/x-patch Size: 2488 bytes Desc: not available URL: From pspacek at redhat.com Thu Aug 11 13:10:37 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Aug 2016 15:10:37 +0200 Subject: [Freeipa-devel] [PATCH 0156] server upgrade: do not start BIND if it was not running before the upgrad Message-ID: <81e85801-f9bd-1024-4c89-3fe2387271fc@redhat.com> Hello, server upgrade: do not start BIND if it was not running before the upgrade https://fedorahosted.org/freeipa/ticket/6206 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0156-server-upgrade-do-not-start-BIND-if-it-was-not-runni.patch Type: text/x-patch Size: 1086 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 11 13:10:39 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 15:10:39 +0200 Subject: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate In-Reply-To: <10819e26-5430-33ef-65b9-3f59c5f8ba9e@redhat.com> References: <1004948019.9643194.1469705403940.JavaMail.zimbra@redhat.com> <11d0579b-2ca2-af88-ed97-2efa477290c0@redhat.com> <529785673.9646711.1469705707399.JavaMail.zimbra@redhat.com> <47d419bd-2b40-8573-2c65-c22a255f5607@redhat.com> <21609031-d13b-eb27-f945-513d244d18cf@redhat.com> <10819e26-5430-33ef-65b9-3f59c5f8ba9e@redhat.com> Message-ID: On 11.08.2016 08:40, Lenka Doudova wrote: > > > > On 08/10/2016 05:48 PM, Martin Basti wrote: >> >> >> >> On 08.08.2016 10:30, Martin Basti wrote: >>> >>> >>> >>> On 02.08.2016 14:50, Lenka Doudova wrote: >>>> >>>> >>>> >>>> On 07/29/2016 11:43 AM, Lenka Doudova wrote: >>>>> >>>>> >>>>> >>>>> On 07/29/2016 11:41 AM, Lenka Doudova wrote: >>>>>> >>>>>> On 07/28/2016 01:35 PM, Peter Lacko wrote: >>>>>>> Hops, fixed. >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Lenka Doudova" >>>>>>> To:freeipa-devel at redhat.com >>>>>>> Sent: Thursday, July 28, 2016 1:32:25 PM >>>>>>> Subject: Re: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I cannot find any attached patch :) >>>>>>> >>>>>>> Lenka >>>>>>> >>>>>>> >>>>>>> On 07/28/2016 01:30 PM, Peter Lacko wrote: >>>>>>>> Attached you can find a patch adding test for URIs in generated certificate >>>>>>>> ipatests/test_xmlrpc/test_cert_plugin.py >>>>>>>> Since I'm leaving Red Hat in end of July, I won't be able to modify this patch anymore. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>> >>>>>>> >>>>>> Hi, >>>>>> >>>>>> NACK. Code looks fine and works well on master branch, but patch >>>>>> does not apply on 4-3 and 4-2 branches. >>>>>> Peter left the company but claimed he can fix the patch if >>>>>> necessary, I'll communicate it with him or fix it myself. >>>>>> >>>>>> Lenka >>>>>> >>>>>> >>>>> Oh, and forgot this one - PEP8 error: >>>>> ./ipatests/test_xmlrpc/test_cert_plugin.py:191:80: E501 line too >>>>> long (105 > 79 characters) >>>>> >>>>> Lenka >>>>> >>>>> >>>> Hi, >>>> >>>> since Peter has quit already, I took it upon myself to do minor fix >>>> and rebase to the patch. >>>> 1) i removed pylint disable comments from the patch, as they were >>>> unnecessary (this also solved PEP8 error) >>>> 2) I rebased the patch to be applicable for ipa-4-3 branch. >>>> Original functionality of the patch remains unchanged. >>>> >>>> Both fixed patches attached. >>>> >>>> Lenka >>>> >>>> >>> >>> Hello, >>> >>> 1) >>> This is not needed >>> + global sn >>> + >>> + result = api.Command.cert_show(sn, out=unicode(self.certfile)) >>> >>> you need the global statement only for write access. But sn is not assigned in this code block. >>> >>> 2) >>> I prefer to use instance attributes (self.sn) instead of global variables >> >> As we figured out, pytest creates for each test new instance of >> class, so 2) will not fork. >> Please fix only 1), sorry. >> >> Martin^2 > Hi, > attached fixed patches for master and 4.3 branches. > > Lenka > >> >>> Martin^2 >>> >>> >> > ACK Pushed to master: 019f3611c299532cd89321767b0e0e4df0d0db27 Pushed to ipa-4-3: 2a207dd637748a4c05e54755b755986fbed16d55 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Aug 11 13:17:35 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Aug 2016 15:17:35 +0200 Subject: [Freeipa-devel] [PATCH 0156] server upgrade: do not start BIND if it was not running before the upgrad In-Reply-To: <81e85801-f9bd-1024-4c89-3fe2387271fc@redhat.com> References: <81e85801-f9bd-1024-4c89-3fe2387271fc@redhat.com> Message-ID: On 11.8.2016 15:10, Petr Spacek wrote: > Hello, > > server upgrade: do not start BIND if it was not running before the upgrade > > https://fedorahosted.org/freeipa/ticket/6206 Here is variant for master branch. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0157-DNS-server-upgrade-do-not-fail-when-DNS-server-did-n.patch Type: text/x-patch Size: 2479 bytes Desc: not available URL: From pspacek at redhat.com Thu Aug 11 13:18:18 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Aug 2016 15:18:18 +0200 Subject: [Freeipa-devel] [PATCH 0156] server upgrade: do not start BIND if it was not running before the upgrad In-Reply-To: References: <81e85801-f9bd-1024-4c89-3fe2387271fc@redhat.com> Message-ID: On 11.8.2016 15:17, Petr Spacek wrote: > On 11.8.2016 15:10, Petr Spacek wrote: >> Hello, >> >> server upgrade: do not start BIND if it was not running before the upgrade >> >> https://fedorahosted.org/freeipa/ticket/6206 > > Here is variant for master branch. Grr, this is a wrong thread. Please ignore this. -- Petr^2 Spacek From pspacek at redhat.com Thu Aug 11 13:18:43 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Aug 2016 15:18:43 +0200 Subject: [Freeipa-devel] [PATCH 0155] DNS server upgrade: do not fail when DNS server did not respond In-Reply-To: <44f963a2-5e4d-2d34-4e6d-b9b58d6c6f5e@redhat.com> References: <44f963a2-5e4d-2d34-4e6d-b9b58d6c6f5e@redhat.com> Message-ID: On 11.8.2016 15:08, Petr Spacek wrote: > Hello, > > DNS server upgrade: do not fail when DNS server did not respond > > Previously, update_dnsforward_emptyzones failed with an exeception if > DNS query failed for some reason. Now the error is logged and upgrade > continues. > > I assume that this is okay because the DNS query is used as heuristics > of last resort in the upgrade logic and failure to do so should not have > catastrophics consequences: In the worst case, the admin needs to > manually change forwarding policy from 'first' to 'only'. > > In the end I have decided not to auto-start BIND because BIND depends on > GSSAPI for authentication, which in turn depends on KDC ... Alternative > like reconfiguring BIND to use LDAPI+EXTERNAL and reconfiguring DS to > accept LDAP external bind from named user are too complicated. > > https://fedorahosted.org/freeipa/ticket/6205 Here is variant for master branch. Enjoy. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0157-DNS-server-upgrade-do-not-fail-when-DNS-server-did-n.patch Type: text/x-patch Size: 2479 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 11 13:34:40 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 15:34:40 +0200 Subject: [Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install In-Reply-To: <5136b336-d64a-90a7-0e7f-a9a794abd6a6@redhat.com> References: <4975c47e-ce78-9e73-7849-f0d77909db7f@redhat.com> <2337c1e9-8d5a-8329-4e11-426b7f231839@redhat.com> <235931cd-67d6-6266-06cb-bd294395e1f3@redhat.com> <5af4f271-4add-ea82-2179-c9357fdac3d9@redhat.com> <1095646d-d146-3462-4158-11be0cc675f1@redhat.com> <5136b336-d64a-90a7-0e7f-a9a794abd6a6@redhat.com> Message-ID: On 09.08.2016 15:27, Stanislav Laznicka wrote: > On 08/04/2016 07:34 AM, Jan Cholasta wrote: >> On 3.8.2016 19:39, Martin Basti wrote: >>> >>> >>> On 03.08.2016 18:10, Petr Vobornik wrote: >>>> On 07/13/2016 12:36 PM, Stanislav Laznicka wrote: >>>>> On 07/13/2016 09:51 AM, Petr Vobornik wrote: >>>>>> On 07/13/2016 08:26 AM, Stanislav Laznicka wrote: >>>>>>> On 07/12/2016 08:44 AM, Stanislav Laznicka wrote: >>>>>>>> On 07/11/2016 04:27 PM, Petr Vobornik wrote: >>>>>>>>> On 07/11/2016 01:23 PM, Stanislav Laznicka wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6046 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Isn't the bug about something else? >>>>>>>>> >>>>>>>>> The issue was that ipa-replica-install doesn't have --force-ntpd >>>>>>>>> option. >>>>>>>>> It is an option of ipa-client-install which is run from replica >>>>>>>>> installer. >>>>>>>>> >>>>>>>>> The unattended mode is unrelated. >>>>>>>> My understanding is that the bug says that '--force-ntpd' option >>>>>>>> should not be shown when ipa-client-install is run during replica >>>>>>>> installation. >>>>>>>> >>>>>>>> During replica installation, the ipa-client-install script is run >>>>>>>> with >>>>>>>> the '--unattended' flag in the 'ensure_enrolled()' function. >>>>>>>> Being a >>>>>>>> separate script, there's not many options on how to pass the >>>>>>>> information not to show the message to ipa-client-install. >>>>>>>> Using the >>>>>>>> already used flag to get rid of the message seemed easiest to me. >>>>>>>> Introducing a new 'hidden' flag (like '--from-replica'), on the >>>>>>>> other >>>>>>>> hand, seems a bit harsh. >>>>>>>> >>>>>>> Just to throw it out there - it's possible that the '--force-join' >>>>>>> client option would also appear as a hint from the client install >>>>>>> script >>>>>>> (during replica installation). Should this also be muted somehow? >>>>>>> To me, >>>>>>> it seems reasonable to rather add it as an argument to >>>>>>> ipa-replica-install to pass it to the client install script. >>>>>>> >>>>>> IMO client installation initiated from replica needs to have a >>>>>> special >>>>>> option(hidden in help) similar to --on-server (or what's its name). >>>>>> E.g. >>>>>> the name can be --replica-install. Maybe --on-server can be used >>>>>> but it >>>>>> may have other implication which might not be valid for this use >>>>>> case. >>>>>> >>>>>> Anything else are just workarounds. Imagine that admin runs >>>>>> ipa-client-install with --unattended or --force-join. He would >>>>>> then not >>>>>> get the message as now. >>>> Reviving thread to get other opinion. >>>> >>>>> The --on-master option won't do here as it seems that the client >>>>> would >>>>> require some IPA pre-configuration for successful install. A new >>>>> option >>>>> will have to be created, then. >>>> I'm for new "hidden" option. >>> >>> I'm against any hidden options, this should be made correctly by >>> modularization/fixing of client install, to be able call it from python >>> not as external process >> >> +1, but this is non-trivial and definitely not material for 4.4.1. >> For 4.4.1 the hidden option should be OK. >> >>> >>> Just from top of my head, can we just use option --no-ntp with client >>> install in replica installer? Server NTP should not depend on client >>> ntp >>> config. >>> I'm just afraid that we may get kerberos time issue during client >>> install if client time does not match server time. >>> >>> Or second approach, always call client install from replica with >>> --force-ntpd, unless there is --no-ntp used for replica, then call >>> ipa-client-install with --no-ntp >>> >>> But it needs investigation. >> >> CCing David as he knows everything NTP-related. >> >>> >>> Martin^2 >>> >>>> >>>>> As I was trying to point out, the situation about --force-join is >>>>> a bit >>>>> different. The option again would be shown and is not available in >>>>> ipa-replica-install. I think it should be available to allow direct >>>>> replica installation even when previous installation failed/left some >>>>> mess on the master (ofc the user could run `ipa-replica-manage del >>>>> --cleanup` on the master instead). >>>>> >>>> That could work but imho is out of scope of this ticket. >>> >> >> > Please see the attached patch that always adds the --no-ntp option to > ipa-client-install. > ACK Pushed to master: 0745c5d0f96f572a3780b32a3f2dce4f3512c396 From jcholast at redhat.com Thu Aug 11 13:40:34 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Aug 2016 15:40:34 +0200 Subject: [Freeipa-devel] [PATCH] 0001: Silence sshd messages during install In-Reply-To: <40c23042-0d7b-c9a8-6c3a-124363897fe3@redhat.com> References: <3fe0b9ae-9b22-3a9a-3d4a-067c51a22452@redhat.com> <19dd378c-cc99-90f5-411c-7f472b87775f@redhat.com> <20160808115831.s7eylgmmdrg5sift@redhat.com> <40c23042-0d7b-c9a8-6c3a-124363897fe3@redhat.com> Message-ID: <301eae1a-6c7b-010d-2716-cca4e4688d47@redhat.com> On 8.8.2016 14:25, Martin Basti wrote: > > > On 08.08.2016 13:58, Alexander Bokovoy wrote: >> On Mon, 08 Aug 2016, Jan Cholasta wrote: >>> On 19.7.2016 08:40, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 9.7.2016 14:46, Ben Lipton wrote: >>>>> On 07/07/2016 11:19 AM, Ben Lipton wrote: >>>>>> >>>>>> Thanks for the review! Comments below. >>>>>> >>>>>> >>>>>> On 07/01/2016 07:42 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 29.06.2016 20:46, Ben Lipton wrote: >>>>>>>> The attached patch silences some annoying messages I've been >>>>>>>> getting >>>>>>>> when upgrading the freeipa-client package on F24: >>>>>>>> """ >>>>>>>> WARNING: 'UseLogin yes' is not supported in Fedora and may cause >>>>>>>> several problems. >>>>>> This will be fixed by openssh-7.2p2-9.fc24 >>>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=1350347) so we probably >>>>>> shouldn't worry about it. >>>>>>>> Could not load host key: /etc/ssh/ssh_host_dsa_key >>>>>> This is because by default sshd looks for all of >>>>>> /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, >>>>>> /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key, but >>>>>> Fedora doesn't generate a DSA key by default. >>>>>>>> """ >>>>>>>> >>>>>>>> Since the script causing the message only looks at the return code >>>>>>>> from sshd to determine the right options to use, I thought it might >>>>>>>> be ok to discard the output. What do you think? >>>>>>>> >>>>>>>> Ben >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Hello, I don't like to hiding errors/warnings. Can you determine and >>>>>>> solve the root cause? >>>>>> >>>>>> I definitely agree with this in principle, but in this case the >>>>>> purpose of this code is to try different, potentially wrong, >>>>>> parameters to sshd until it finds a combination that it accepts. It >>>>>> seems like in some environments this would produce error messages >>>>>> that >>>>>> aren't actionable and don't indicate any problem for package >>>>>> function, >>>>>> which is why I didn't think these messages were necessarily worth >>>>>> preserving. >>>>>> >>>>>> On the other hand, if the code makes the wrong decision about sshd >>>>>> version we might be interested in error logs that show why. Can we >>>>>> log >>>>>> this to a file instead of the console, maybe? >>>>>> >>>>>> If you'd prefer just addressing the root cause, a patch that prevents >>>>>> the missing host key error is attached, but it won't stop the error >>>>>> messages showing up when openssh is an older version. >>>>>> >>>>>> Thanks, >>>>>> Ben >>>>>> >>>>>> >>>>> Whoops, realized that my patch created a tempfile and didn't delete >>>>> it. >>>>> Updated. >>>> >>>> I think the first version of the patch was OK. sshd is called only to >>>> check which set of authorized keys options to use, we don't really care >>>> about anything else, so we can safely ignore whatever it puts to >>>> stderr. >>> >>> Bump. >>> >>> ACK on the first version of the patch >>> (freeipa-blipton-0001-Silence-sshd-messages-during-install.patch). >>> >>> Anyone against pushing it? >> Given that newer OpenSSH version will silence it anyway, I'm OK with the >> interim fix. > Pushed to master: c15ba1f9e8c7d236586d46271fce7c3950b509da You pushed the wrong patch (0002). -- Jan Cholasta From mbasti at redhat.com Thu Aug 11 13:45:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 15:45:44 +0200 Subject: [Freeipa-devel] [PATCH] 0001: Silence sshd messages during install In-Reply-To: <301eae1a-6c7b-010d-2716-cca4e4688d47@redhat.com> References: <3fe0b9ae-9b22-3a9a-3d4a-067c51a22452@redhat.com> <19dd378c-cc99-90f5-411c-7f472b87775f@redhat.com> <20160808115831.s7eylgmmdrg5sift@redhat.com> <40c23042-0d7b-c9a8-6c3a-124363897fe3@redhat.com> <301eae1a-6c7b-010d-2716-cca4e4688d47@redhat.com> Message-ID: On 11.08.2016 15:40, Jan Cholasta wrote: > On 8.8.2016 14:25, Martin Basti wrote: >> >> >> On 08.08.2016 13:58, Alexander Bokovoy wrote: >>> On Mon, 08 Aug 2016, Jan Cholasta wrote: >>>> On 19.7.2016 08:40, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 9.7.2016 14:46, Ben Lipton wrote: >>>>>> On 07/07/2016 11:19 AM, Ben Lipton wrote: >>>>>>> >>>>>>> Thanks for the review! Comments below. >>>>>>> >>>>>>> >>>>>>> On 07/01/2016 07:42 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 29.06.2016 20:46, Ben Lipton wrote: >>>>>>>>> The attached patch silences some annoying messages I've been >>>>>>>>> getting >>>>>>>>> when upgrading the freeipa-client package on F24: >>>>>>>>> """ >>>>>>>>> WARNING: 'UseLogin yes' is not supported in Fedora and may cause >>>>>>>>> several problems. >>>>>>> This will be fixed by openssh-7.2p2-9.fc24 >>>>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=1350347) so we >>>>>>> probably >>>>>>> shouldn't worry about it. >>>>>>>>> Could not load host key: /etc/ssh/ssh_host_dsa_key >>>>>>> This is because by default sshd looks for all of >>>>>>> /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, >>>>>>> /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key, but >>>>>>> Fedora doesn't generate a DSA key by default. >>>>>>>>> """ >>>>>>>>> >>>>>>>>> Since the script causing the message only looks at the return >>>>>>>>> code >>>>>>>>> from sshd to determine the right options to use, I thought it >>>>>>>>> might >>>>>>>>> be ok to discard the output. What do you think? >>>>>>>>> >>>>>>>>> Ben >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Hello, I don't like to hiding errors/warnings. Can you >>>>>>>> determine and >>>>>>>> solve the root cause? >>>>>>> >>>>>>> I definitely agree with this in principle, but in this case the >>>>>>> purpose of this code is to try different, potentially wrong, >>>>>>> parameters to sshd until it finds a combination that it accepts. It >>>>>>> seems like in some environments this would produce error messages >>>>>>> that >>>>>>> aren't actionable and don't indicate any problem for package >>>>>>> function, >>>>>>> which is why I didn't think these messages were necessarily worth >>>>>>> preserving. >>>>>>> >>>>>>> On the other hand, if the code makes the wrong decision about sshd >>>>>>> version we might be interested in error logs that show why. Can we >>>>>>> log >>>>>>> this to a file instead of the console, maybe? >>>>>>> >>>>>>> If you'd prefer just addressing the root cause, a patch that >>>>>>> prevents >>>>>>> the missing host key error is attached, but it won't stop the error >>>>>>> messages showing up when openssh is an older version. >>>>>>> >>>>>>> Thanks, >>>>>>> Ben >>>>>>> >>>>>>> >>>>>> Whoops, realized that my patch created a tempfile and didn't delete >>>>>> it. >>>>>> Updated. >>>>> >>>>> I think the first version of the patch was OK. sshd is called only to >>>>> check which set of authorized keys options to use, we don't really >>>>> care >>>>> about anything else, so we can safely ignore whatever it puts to >>>>> stderr. >>>> >>>> Bump. >>>> >>>> ACK on the first version of the patch >>>> (freeipa-blipton-0001-Silence-sshd-messages-during-install.patch). >>>> >>>> Anyone against pushing it? >>> Given that newer OpenSSH version will silence it anyway, I'm OK with >>> the >>> interim fix. >> Pushed to master: c15ba1f9e8c7d236586d46271fce7c3950b509da > > You pushed the wrong patch (0002). > Yes, sorry, I forgot how to numbers Fixed patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0001-Silence-sshd-messages-during-install.patch Type: text/x-patch Size: 2720 bytes Desc: not available URL: From tbordaz at redhat.com Thu Aug 11 13:56:23 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 11 Aug 2016 15:56:23 +0200 Subject: [Freeipa-devel] [PATCH] 0024 memory leak in ipapwd plugin In-Reply-To: <20160810171927.fzjktnorevhlv46e@redhat.com> References: <57AACBB9.1050608@redhat.com> <20160810092441.wmgv6jtrrej7bbxi@redhat.com> <57AB55A3.6040305@redhat.com> <20160810171927.fzjktnorevhlv46e@redhat.com> Message-ID: <57AC8407.70806@redhat.com> On 08/10/2016 07:19 PM, Alexander Bokovoy wrote: > On Wed, 10 Aug 2016, thierry bordaz wrote: >> >> >> On 08/10/2016 11:24 AM, Alexander Bokovoy wrote: >>> On Wed, 10 Aug 2016, thierry bordaz wrote: >>>> >>> >>>>> From 13bb55f9d97f82062f5b496d4164acb562afc7a0 Mon Sep 17 00:00:00 >>>>> 2001 >>>> From: Thierry Bordaz >>>> Date: Tue, 9 Aug 2016 16:46:25 +0200 >>>> Subject: [PATCH] ipa-pwd-extop memory leak during passord update >>>> >>>> During an extend op password update, there is a test if the >>>> user is changing the password is himself. It uses local Slapi_SDN >>>> variable that are not freed >>>> --- >>>> daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 8 ++++++-- >>>> 1 file changed, 6 insertions(+), 2 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 6a87a27..2eda6c6 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 >>>> @@ -398,16 +398,20 @@ parse_req_done: >>>> /* if the user changing the password is self, we must >>>> request the >>>> * old password and verify it matches the current one before >>>> * proceeding with the password change */ >>>> - bind_sdn = slapi_sdn_new_dn_byref(bindDN); >>>> - target_sdn = slapi_sdn_new_dn_byref(dn); >>>> + bind_sdn = slapi_sdn_new_dn_byval(bindDN); >>>> + target_sdn = slapi_sdn_new_dn_byval(dn); >>>> if (!bind_sdn || !target_sdn) { >>>> LOG_OOM(); >>>> + slapi_sdn_free(&bind_sdn); >>>> + slapi_sdn_free(&target_sdn); >>>> rc = LDAP_OPERATIONS_ERROR; >>>> goto free_and_return; >>>> } >>>> /* this one will normalize and compare, so difference in >>>> case will be >>>> * correctly handled */ >>>> ret = slapi_sdn_compare(bind_sdn, target_sdn); >>>> + slapi_sdn_free(&bind_sdn); >>>> + slapi_sdn_free(&target_sdn); >>>> if (ret == 0) { >>>> Slapi_Value *cpw[2] = { NULL, NULL }; >>>> Slapi_Value *pw; >>> I would prefer to unify memory freeing. Because slapi_sdn_compare() can >>> be run with NULL arguments (it will return 0), and slapi_sdn_free() is >>> no-op for NULL argument, you can actually do comparison, then free the >>> SDNs and then do error handling: >>> >>> >>> bind_sdn = slapi_sdn_new_dn_byval(bindDN); >>> target_sdn = slapi_sdn_new_dn_byval(dn); >>> >>> rc = (!bind_sdn || !target_sdn) ? LDAP_OPERATIONS_ERROR : 0; >>> ret = slapi_sdn_compare(bind_sdn, target_sdn); >>> >>> slapi_sdn_free(&bind_sdn); >>> slapi_sdn_free(&target_sdn); >>> >>> if (rc != 0) { >>> LOG_OOM(); >>> goto free_and_return; >>> } >>> >>> if (ret == 0) { >>> .... >>> } >>> >>> >>> >>>> -- >>>> 2.7.4 >>>> >>> >>>> -- >>>> Manage your subscription for the Freeipa-devel mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code >>> >>> >> Thanks again Alexander for the review. Here is the revisited patch > >> From db4211d855b4d21354dc619952b2b2e1ad31f3b9 Mon Sep 17 00:00:00 2001 >> From: Thierry Bordaz >> Date: Tue, 9 Aug 2016 16:46:25 +0200 >> Subject: [PATCH] ipa-pwd-extop memory leak during passord update >> >> During an extend op password update, there is a test if the >> user is changing the password is himself. It uses local Slapi_SDN >> variable that are not freed >> --- >> .../ipa-pwd-extop/ipa_pwd_extop.c | 24 >> +++++++++++++++------- >> 1 file changed, 17 insertions(+), 7 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 6a87a27..eaca0dc 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 >> @@ -398,16 +398,26 @@ parse_req_done: >> /* if the user changing the password is self, we must request >> the >> * old password and verify it matches the current one before >> * proceeding with the password change */ >> - bind_sdn = slapi_sdn_new_dn_byref(bindDN); >> - target_sdn = slapi_sdn_new_dn_byref(dn); >> - if (!bind_sdn || !target_sdn) { >> - LOG_OOM(); >> - rc = LDAP_OPERATIONS_ERROR; >> - goto free_and_return; >> - } >> + bind_sdn = slapi_sdn_new_dn_byval(bindDN); >> + target_sdn = slapi_sdn_new_dn_byval(dn); >> + >> + rc = (!bind_sdn || !target_sdn) ? LDAP_OPERATIONS_ERROR : 0; >> + >> /* this one will normalize and compare, so difference in case >> will be >> * correctly handled */ >> ret = slapi_sdn_compare(bind_sdn, target_sdn); >> + >> + slapi_sdn_free(&bind_sdn); >> + slapi_sdn_free(&target_sdn); >> + >> + /* rc should always be 0 (else slapi_sdn_new_dn_byref should >> have sigsev) >> + * but if we end in rc==LDAP_OPERATIONS_ERROR be sure to >> stop here >> + * because ret is not significant */ > A short note here. You talk about slapi_sdn_new_dn_byref() but your > patch replaces that with slapi_sdn_new_dn_byval(). Does the comment > still apply? > >> + if (rc != 0) { >> + LOG_OOM(); >> + goto free_and_return; >> + } >> + >> if (ret == 0) { >> Slapi_Value *cpw[2] = { NULL, NULL }; >> Slapi_Value *pw; >> -- >> 2.7.4 >> > > Good catch Alexander. Yes the comment contained a wrong cut/paste -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-44-tbordaz-024-3-ipa-pwd-extop-memory-leak-during-passord-update.patch Type: text/x-patch Size: 2115 bytes Desc: not available URL: From jcholast at redhat.com Thu Aug 11 14:09:07 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Aug 2016 16:09:07 +0200 Subject: [Freeipa-devel] [PATCHES 681-682] cert: speed up cert-find, do not crash on invalid data in cert-find In-Reply-To: <35ddad7d-664a-1231-c8ae-afd4d4b43443@redhat.com> References: <5fdd4314-7c3f-242d-1648-0aae521f1743@redhat.com> <35ddad7d-664a-1231-c8ae-afd4d4b43443@redhat.com> Message-ID: On 11.8.2016 14:27, Martin Basti wrote: > > > On 01.08.2016 10:27, Jan Cholasta wrote: >> On 1.8.2016 10:19, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches fix >>> and . >> >> Self-NACK, proper patches attached. >> >> Honza >> >> >> > > IMHO this is caused by your patches, test_cert_plugin.py: Fixed. Updated and rebased patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-681.2-cert-speed-up-cert-find.patch Type: text/x-patch Size: 18430 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-682.2-cert-do-not-crash-on-invalid-data-in-cert-find.patch Type: text/x-patch Size: 2598 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 11 14:13:37 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 16:13:37 +0200 Subject: [Freeipa-devel] [PATCH 0035] Remove Custodia server keys from LDAP In-Reply-To: References: Message-ID: <0e0ece56-30cc-a2f5-2fd3-72370a498481@redhat.com> On 08.08.2016 16:10, Christian Heimes wrote: > The server-del plugin now removes the Custodia keys for encryption and > key signing from LDAP. > > https://fedorahosted.org/freeipa/ticket/6015 > > ACK for master For 4.3, it requires new patch Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvomacka at redhat.com Thu Aug 11 14:18:55 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 11 Aug 2016 16:18:55 +0200 Subject: [Freeipa-devel] [PATCH] 0102-0104: webui: Add support for setting custom table pagination size Message-ID: <4f758e21-b951-9ca6-e685-29746c1cec44@redhat.com> Hello, please review attached patches. https://fedorahosted.org/freeipa/ticket/5742 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0102-Add-javascript-integer-validator.patch Type: text/x-patch Size: 2127 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0103-Make-singleton-from-config-module.patch Type: text/x-patch Size: 2435 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0104-Add-support-for-custom-table-pagination-size.patch Type: text/x-patch Size: 9623 bytes Desc: not available URL: From abokovoy at redhat.com Thu Aug 11 14:39:03 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Aug 2016 17:39:03 +0300 Subject: [Freeipa-devel] [PATCH] 0024 memory leak in ipapwd plugin In-Reply-To: <57AC8407.70806@redhat.com> References: <57AACBB9.1050608@redhat.com> <20160810092441.wmgv6jtrrej7bbxi@redhat.com> <57AB55A3.6040305@redhat.com> <20160810171927.fzjktnorevhlv46e@redhat.com> <57AC8407.70806@redhat.com> Message-ID: <20160811143903.id66th5o63vhkpqi@redhat.com> On Thu, 11 Aug 2016, thierry bordaz wrote: >>>+ /* rc should always be 0 (else slapi_sdn_new_dn_byref >>>should have sigsev) >>>+ * but if we end in rc==LDAP_OPERATIONS_ERROR be sure to >>>stop here >>>+ * because ret is not significant */ >>A short note here. You talk about slapi_sdn_new_dn_byref() but your >>patch replaces that with slapi_sdn_new_dn_byval(). Does the comment >>still apply? >> >>>+ if (rc != 0) { >>>+ LOG_OOM(); >>>+ goto free_and_return; >>>+ } >>>+ >>> if (ret == 0) { >>> Slapi_Value *cpw[2] = { NULL, NULL }; >>> Slapi_Value *pw; >>>-- >>>2.7.4 >>> >> >> >Good catch Alexander. Yes the comment contained a wrong cut/paste ACK. -- / Alexander Bokovoy From mbasti at redhat.com Thu Aug 11 15:38:38 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 17:38:38 +0200 Subject: [Freeipa-devel] [PATCH 0155] DNS server upgrade: do not fail when DNS server did not respond In-Reply-To: References: <44f963a2-5e4d-2d34-4e6d-b9b58d6c6f5e@redhat.com> Message-ID: On 11.08.2016 15:18, Petr Spacek wrote: > On 11.8.2016 15:08, Petr Spacek wrote: >> Hello, >> >> DNS server upgrade: do not fail when DNS server did not respond >> >> Previously, update_dnsforward_emptyzones failed with an exeception if >> DNS query failed for some reason. Now the error is logged and upgrade >> continues. >> >> I assume that this is okay because the DNS query is used as heuristics >> of last resort in the upgrade logic and failure to do so should not have >> catastrophics consequences: In the worst case, the admin needs to >> manually change forwarding policy from 'first' to 'only'. >> >> In the end I have decided not to auto-start BIND because BIND depends on >> GSSAPI for authentication, which in turn depends on KDC ... Alternative >> like reconfiguring BIND to use LDAPI+EXTERNAL and reconfiguring DS to >> accept LDAP external bind from named user are too complicated. >> >> https://fedorahosted.org/freeipa/ticket/6205 > Here is variant for master branch. Enjoy. > ACK From mbasti at redhat.com Thu Aug 11 15:39:37 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 17:39:37 +0200 Subject: [Freeipa-devel] [PATCH 0156] server upgrade: do not start BIND if it was not running before the upgrad In-Reply-To: <81e85801-f9bd-1024-4c89-3fe2387271fc@redhat.com> References: <81e85801-f9bd-1024-4c89-3fe2387271fc@redhat.com> Message-ID: <96f7f682-7570-490c-78cb-73069fec4d60@redhat.com> On 11.08.2016 15:10, Petr Spacek wrote: > Hello, > > server upgrade: do not start BIND if it was not running before the upgrade > > https://fedorahosted.org/freeipa/ticket/6206 > > > ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvomacka at redhat.com Thu Aug 11 16:57:17 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 11 Aug 2016 18:57:17 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> Message-ID: <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> On 08/11/2016 02:00 PM, Petr Vobornik wrote: > On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >> On Thu, 11 Aug 2016, Jan Cholasta wrote: >>> On 4.8.2016 17:27, Jan Pazdziora wrote: >>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >>>>> Got it. One thing I would correct, though, -- don't use >>>>> kadmin.local, we >>>>> do support setting ok_as_delegate on the service principals via IPA >>>>> CLI: >>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>>>> --ok-as-delegate=BOOL >>>>> Client credentials may be delegated to the >>>>> service >>>> I've tried >>>> >>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >>>> >>>> but that does not seem to have the same effect as >>>> >>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >>>> >>>> -- obtaining the delegated certificated fails. >>> That's because ok_as_delegate and ok_to_auth_as_delegate are different >>> flags. >> Right. The following patch adds ok_to_auth_as_delegate to the service >> principal. >> >> I haven't added any tickets to it yet. >> >> > This might deserve also nice Web UI checkbox similar to "Trusted for > delegation". CCing Pavel. > Here is patch with new checkbox. It is without ticket in commit message so once we will have the ticket I will send another patch witch updated commit message. -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0105-Add-trusted-to-auth-as-user-checkbox.patch Type: text/x-patch Size: 1091 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 11 17:21:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 19:21:00 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> Message-ID: <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> On 11.08.2016 18:57, Pavel Vomacka wrote: > > > On 08/11/2016 02:00 PM, Petr Vobornik wrote: >> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >>>>>> Got it. One thing I would correct, though, -- don't use >>>>>> kadmin.local, we >>>>>> do support setting ok_as_delegate on the service principals via IPA >>>>>> CLI: >>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>>>>> --ok-as-delegate=BOOL >>>>>> Client credentials may be delegated to the >>>>>> service >>>>> I've tried >>>>> >>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >>>>> >>>>> but that does not seem to have the same effect as >>>>> >>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >>>>> >>>>> -- obtaining the delegated certificated fails. >>>> That's because ok_as_delegate and ok_to_auth_as_delegate are different >>>> flags. >>> Right. The following patch adds ok_to_auth_as_delegate to the service >>> principal. >>> >>> I haven't added any tickets to it yet. >>> >>> >> This might deserve also nice Web UI checkbox similar to "Trusted for >> delegation". CCing Pavel. >> > Here is patch with new checkbox. It is without ticket in commit > message so once we will have the ticket I will send another patch > witch updated commit message. https://fedorahosted.org/freeipa/newticket ;-) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Aug 11 17:43:05 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Aug 2016 19:43:05 +0200 Subject: [Freeipa-devel] [PATCHES 681-682] cert: speed up cert-find, do not crash on invalid data in cert-find In-Reply-To: References: <5fdd4314-7c3f-242d-1648-0aae521f1743@redhat.com> <35ddad7d-664a-1231-c8ae-afd4d4b43443@redhat.com> Message-ID: On 11.08.2016 16:09, Jan Cholasta wrote: > On 11.8.2016 14:27, Martin Basti wrote: >> >> >> On 01.08.2016 10:27, Jan Cholasta wrote: >>> On 1.8.2016 10:19, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches fix >>>> >>>> and . >>> >>> Self-NACK, proper patches attached. >>> >>> Honza >>> >>> >>> >> >> IMHO this is caused by your patches, test_cert_plugin.py: > > Fixed. > > Updated and rebased patches attached. > Hello, It works for me, but: 1) Is this py2/3 compatible? ra_obj = ra.get_certificate(str(serial_number)) 2) Are you sure you need tuple() here? + for key in tuple(six.iterkeys(result)): 3) if cert is not None: filter = ldap.make_filter_from_attr('usercertificate', value) filters.append(filter) Variable "value" may be referenced before assignment I haven't tested performace improvements yet, and it is quite big change so I will continue with testing tomorrow. Martin^2 From pvoborni at redhat.com Thu Aug 11 17:49:45 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 11 Aug 2016 19:49:45 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> Message-ID: <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> On 08/11/2016 07:21 PM, Martin Basti wrote: > > > On 11.08.2016 18:57, Pavel Vomacka wrote: >> >> >> On 08/11/2016 02:00 PM, Petr Vobornik wrote: >>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >>>>>>> Got it. One thing I would correct, though, -- don't use >>>>>>> kadmin.local, we >>>>>>> do support setting ok_as_delegate on the service principals via IPA >>>>>>> CLI: >>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>>>>>> --ok-as-delegate=BOOL >>>>>>> Client credentials may be delegated to the >>>>>>> service >>>>>> I've tried >>>>>> >>>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >>>>>> >>>>>> but that does not seem to have the same effect as >>>>>> >>>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >>>>>> >>>>>> -- obtaining the delegated certificated fails. >>>>> That's because ok_as_delegate and ok_to_auth_as_delegate are different >>>>> flags. >>>> Right. The following patch adds ok_to_auth_as_delegate to the service >>>> principal. >>>> >>>> I haven't added any tickets to it yet. >>>> >>>> >>> This might deserve also nice Web UI checkbox similar to "Trusted for >>> delegation". CCing Pavel. >>> >> Here is patch with new checkbox. It is without ticket in commit message so >> once we will have the ticket I will send another patch witch updated commit >> message. > > https://fedorahosted.org/freeipa/newticket > > ;-) It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 so we might use that. > >> >> >> > > > -- Petr Vobornik From jcholast at redhat.com Fri Aug 12 06:29:04 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 12 Aug 2016 08:29:04 +0200 Subject: [Freeipa-devel] [PATCHES 681-682] cert: speed up cert-find, do not crash on invalid data in cert-find In-Reply-To: References: <5fdd4314-7c3f-242d-1648-0aae521f1743@redhat.com> <35ddad7d-664a-1231-c8ae-afd4d4b43443@redhat.com> Message-ID: On 11.8.2016 19:43, Martin Basti wrote: > > > On 11.08.2016 16:09, Jan Cholasta wrote: >> On 11.8.2016 14:27, Martin Basti wrote: >>> >>> >>> On 01.08.2016 10:27, Jan Cholasta wrote: >>>> On 1.8.2016 10:19, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patches fix >>>>> >>>>> and . >>>> >>>> Self-NACK, proper patches attached. >>>> >>>> Honza >>>> >>>> >>>> >>> >>> IMHO this is caused by your patches, test_cert_plugin.py: >> >> Fixed. >> >> Updated and rebased patches attached. >> > Hello, > > It works for me, but: > > 1) > Is this py2/3 compatible? > ra_obj = ra.get_certificate(str(serial_number)) I don't see why not. Do you have any particular incompatibility in mind? > > 2) > Are you sure you need tuple() here? > + for key in tuple(six.iterkeys(result)): Yes, I'm modifying `result` inside the loop. I don't need the six.iterkeys() though. > > 3) > if cert is not None: > filter = ldap.make_filter_from_attr('usercertificate', value) > filters.append(filter) > > Variable "value" may be referenced before assignment Right, it should be `cert`, not `value`. > > I haven't tested performace improvements yet, and it is quite big change > so I will continue with testing tomorrow. > > Martin^2 -- Jan Cholasta From mbasti at redhat.com Fri Aug 12 06:57:46 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Aug 2016 08:57:46 +0200 Subject: [Freeipa-devel] [PATCHES 681-682] cert: speed up cert-find, do not crash on invalid data in cert-find In-Reply-To: References: <5fdd4314-7c3f-242d-1648-0aae521f1743@redhat.com> <35ddad7d-664a-1231-c8ae-afd4d4b43443@redhat.com> Message-ID: On 12.08.2016 08:29, Jan Cholasta wrote: > On 11.8.2016 19:43, Martin Basti wrote: >> >> >> On 11.08.2016 16:09, Jan Cholasta wrote: >>> On 11.8.2016 14:27, Martin Basti wrote: >>>> >>>> >>>> On 01.08.2016 10:27, Jan Cholasta wrote: >>>>> On 1.8.2016 10:19, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patches fix >>>>>> >>>>>> and . >>>>> >>>>> Self-NACK, proper patches attached. >>>>> >>>>> Honza >>>>> >>>>> >>>>> >>>> >>>> IMHO this is caused by your patches, test_cert_plugin.py: >>> >>> Fixed. >>> >>> Updated and rebased patches attached. >>> >> Hello, >> >> It works for me, but: >> >> 1) >> Is this py2/3 compatible? >> ra_obj = ra.get_certificate(str(serial_number)) > > I don't see why not. Do you have any particular incompatibility in mind? Because there is function str() used, where result is unicode in py3 but not in py2 > >> >> 2) >> Are you sure you need tuple() here? >> + for key in tuple(six.iterkeys(result)): > > Yes, I'm modifying `result` inside the loop. > > I don't need the six.iterkeys() though. sorry, I overlooked that. > >> >> 3) >> if cert is not None: >> filter = ldap.make_filter_from_attr('usercertificate', >> value) >> filters.append(filter) >> >> Variable "value" may be referenced before assignment > > Right, it should be `cert`, not `value`. > >> >> I haven't tested performace improvements yet, and it is quite big change >> so I will continue with testing tomorrow. >> >> Martin^2 > > From jcholast at redhat.com Fri Aug 12 09:33:28 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 12 Aug 2016 11:33:28 +0200 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> Message-ID: <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> On 4.8.2016 18:18, Petr Vobornik wrote: > On 07/22/2016 07:13 AM, Fraser Tweedale wrote: >> On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote: >>> Hi, >>> >>> On 14.7.2016 13:44, Fraser Tweedale wrote: >>>> Hi all, >>>> >>>> The attached patch includes SANs in cert-show output. If you have >>>> certs with esoteric altnames (especially any that are more than just >>>> ASN.1 string types), please test with those certs. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6022 >>> >>> I think it would be better to have a separate attribute for each supported >>> SAN type rather than cramming everything into subject_alt_name. That way if >>> you care only about a single specific type you won't have to go through all >>> the values and parse them. Also it would allow you to use param types >>> appropriate to the SAN types (DNSNameParam for DNS names, Principal for >>> principal names, etc.) >>> >>> Nitpick: please don't mix moving existing stuff and adding new stuff in a >>> single patch. >>> >> Updated patches attached. >> >> Patches 0092..0094 are refactors and bugfixes. >> Patch 0090-2 is the main feature (depends on 0092..0094). >> >> Thanks, >> Fraser >> > > bump for review Patch 0092: ACK Patch 0093: ACK Patch 0094: ACK Patch 0090: 1) Generic otherNames (san_other) do not work correctly. The OID is not included in the value and names with complex type other than KerberosPrincipal are not parsed correctly. The value should include the OID and DER blob of the name. 2) With --all, san_other should be included in the result for all otherNames, even the known ones, to provide (limited) forward compatibility. 3) Do we have to support *all* the name types? I mean we could, for the sake of completeness, but it might be easier to just keep the few ones we actually care about (email, DNS name, principal name, UPN and directory name in your patch 0095). 4) + obj.setdefault(attr_name, []).append(unicode(name)) The value should not (always) be unicode, but of the type declared by the param (unicode or ipapython.kerberos.Principal or ipapython.dnsutil.DNSName). -- Jan Cholasta From slaznick at redhat.com Fri Aug 12 10:08:46 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 12 Aug 2016 12:08:46 +0200 Subject: [Freeipa-devel] [PATCH 0063] Raise error on topology disconnect/last-role-host removal during server uninstall Message-ID: <4b103ebb-cd29-1705-456f-fd7965abc2a6@redhat.com> Hello, topology disconnect/last-role-host removal errors would just be logged during server uninstall even if ignore options are not present. The host would still appear in the topology even after "successful" uninstall. https://fedorahosted.org/freeipa/ticket/6168 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0063-Fail-on-topology-disconnect-last-role-removal.patch Type: text/x-patch Size: 1621 bytes Desc: not available URL: From pspacek at redhat.com Fri Aug 12 10:37:40 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Aug 2016 12:37:40 +0200 Subject: [Freeipa-devel] [PATCH 0433-0434] Fix zone removal to respect forward configuration inheritance + Remove preserve_forwarding parameter from ldap_delete_zone2() Message-ID: Hello, please review attached patch set. It fixes https://fedorahosted.org/bind-dyndb-ldap/ticket/167 The code is also available on Github: https://github.com/pspacek/bind-dyndb-ldap/tree/fix_root_zone_removal Patched SRPM: https://pspacek.fedorapeople.org/bind-dyndb-ldap/bind-dyndb-ldap-10.0-3.fc24.src.rpm COPR build: https://copr.fedorainfracloud.org/coprs/pspacek/bind-dyndb-ldap/build/440841/ Martin Basti, please build it also in @freeipa/freeipa-master COPR so CI can pick it up. Thank you! Patch set description: Fix zone removal to respect forward configuration inheritance. Ad-hoc fwd_delete_table() calls did not respect inheritance hierarchy in forwarding configuration. Now all manipulation with forward table is done in fwd_configure_zone() and fully respects configuration inheritance. There is a trick: When removing or deactivating a zone, fwd_configure_zone() is called with empty configuration set to simulate that the zone does not have any explicit configuration. This triggers the inheritance logic when necessary (i.e. for the root zone). https://fedorahosted.org/bind-dyndb-ldap/ticket/167 https://github.com/pspacek/bind-dyndb-ldap/commit/d6e413c4cc88101b902d73e05e1ce35e2fe4aedd Remove preserve_forwarding parameter from ldap_delete_zone2(). The parameter was TRUE only when called from zone_security_change(). zone_security_change() is calling ldap_delete_zone2() in exclusive mode anyway so there is no need to optimize this. Removal of the parameter will make easier to centralize forwarding configuration on one place. https://fedorahosted.org/bind-dyndb-ldap/ticket/167 https://github.com/pspacek/bind-dyndb-ldap/commit/b40976263460d8f4aeeec2a2a8f41cc54dcd0b28 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0433-Remove-preserve_forwarding-parameter-from-ldap_delet.patch Type: text/x-patch Size: 4884 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0434-Fix-zone-removal-to-respect-forward-configuration-in.patch Type: text/x-patch Size: 2511 bytes Desc: not available URL: From tdudlak at redhat.com Fri Aug 12 12:54:27 2016 From: tdudlak at redhat.com (Tibor Dudlak) Date: Fri, 12 Aug 2016 14:54:27 +0200 Subject: [Freeipa-devel] [PATCH] 0004 Added support for authentication with user certificate Message-ID: Hi, I have edited my previous patch. On Thu, Aug 11, 2016 at 11:52 AM, Jan Cholasta wrote: > Hi, > > On 11.8.2016 09:55, Tibor Dudlak wrote: > >> Hi, >> >> ... >> > > +class login_x509(login_kerberos, KerberosSession, HTTP_Status): > + key = '/session/login_x509' > > login_kerberos already subclasses KerberosSession and HTTP_Status, no need > to do it again here. In fact, it would be best to split off the bussiness > logic from login_kerberos into a separate class and inherit both > login_kerberos and login_x509 from it: > > class KerberosLogin(Backend, KerberosSession, HTTP_Status): > def _on_finalize(self): > ... > > def __call__(self, ...): > ... > > class login_kerberos(KerberosLogin): > key = '/session/login_kerberos' > > class login_x509(KerberosLogin): > key = '/session/login_x509' > > Honza > > -- > Jan Cholasta > Thank jcholast for review, it should be all right now. -- Tibor Dudl?k Intern - Identity management Special Projects Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tdudlak-0004-Added-support-for-authentication-with-user-certificate.patch Type: text/x-patch Size: 11134 bytes Desc: not available URL: From pvoborni at redhat.com Fri Aug 12 13:02:01 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 12 Aug 2016 15:02:01 +0200 Subject: [Freeipa-devel] [PATCH] 0004 Added support for authentication with user certificate In-Reply-To: References: Message-ID: <57383c8e-c4c2-61ad-1045-9e9c20eab4d8@redhat.com> On 08/12/2016 02:54 PM, Tibor Dudlak wrote: > Hi, > > I have edited my previous patch. > > On Thu, Aug 11, 2016 at 11:52 AM, Jan Cholasta > wrote: > > Hi, > > On 11.8.2016 09:55, Tibor Dudlak wrote: > > Hi, > > ... > > > +class login_x509(login_kerberos, KerberosSession, HTTP_Status): > + key = '/session/login_x509' > > login_kerberos already subclasses KerberosSession and HTTP_Status, no need > to do it again here. In fact, it would be best to split off the bussiness > logic from login_kerberos into a separate class and inherit both > login_kerberos and login_x509 from it: > > class KerberosLogin(Backend, KerberosSession, HTTP_Status): > def _on_finalize(self): > ... > > def __call__(self, ...): > ... > > class login_kerberos(KerberosLogin): > key = '/session/login_kerberos' > > class login_x509(KerberosLogin): > key = '/session/login_x509' > > Honza > > -- > Jan Cholasta > > > Thank jcholast for review, it should be all right now. > > -- > Tibor Dudl?k > Intern - Identity management Special Projects > Red Hat > Tibor, please reuse the original thread and patch number in each patch iteration. But append new patch version. E.g. freeipa-ddudla-0003-2-Added... Starting new thread for each patch revision makes it hard to track. -- Petr Vobornik From gkaihoro at redhat.com Fri Aug 12 13:15:50 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Fri, 12 Aug 2016 09:15:50 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts In-Reply-To: References: <256010841.13930537.1470754537126.JavaMail.zimbra@redhat.com> Message-ID: <2060396264.32913492.1471007750745.JavaMail.zimbra@redhat.com> Hello! Thank you for review Attached fixed patch Best regards, Ganna Kaihorodova Associate Software Quality Engineer ----- Original Message ----- From: "Martin Basti" To: "Ganna Kaihorodova" , "freeipa-devel" Sent: Thursday, August 11, 2016 11:00:21 AM Subject: Re: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts On 09.08.2016 16:55, Ganna Kaihorodova wrote: > Hello! > > Domain level 0 doesn't allow to create replica file on CA master, testcase was skipped with Domain level 0 > > https://fedorahosted.org/freeipa/ticket/6134 > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > > Hello, Please fix PEP8 error you introduced. ./ipatests/test_integration/test_replication_layouts.py:32:1: E302 expected 2 blank lines, found 1 IMO this need skip on domain level 0 too * Test2ConnectedTopologyWithoutCA * TestDoubleCircleTopologyWithoutCA Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-gkaihoro-0003-2-Fix-for-integration-tests-replication-layouts.patch Type: text/x-patch Size: 2190 bytes Desc: not available URL: From ofayans at redhat.com Fri Aug 12 13:48:15 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 12 Aug 2016 15:48:15 +0200 Subject: [Freeipa-devel] [Test][patch-0058] Fixed topology tests failures in CI In-Reply-To: References: <57AB735A.3000101@redhat.com> Message-ID: <57ADD39F.8050409@redhat.com> Hi Martin, On 08/11/2016 10:05 AM, Martin Basti wrote: > > > On 10.08.2016 20:32, Oleg Fayans wrote: >> >> >> > Hello, > > before we jump into fixing tests, my question is: Was this planned > change and not reflected by test, or switched values are unwanted side > effect and thus bug for us? That's a marvelous question! The test used to pass, which means that at some point the convention of naming the segments must have changed. Is it a bug? I do not think so: the feature still works as expected. > > Ticket contains almost no info, except a traceback and it says nothing. > Commit message says at least something. > > I'm not sure if this patch fixes that ticket, because traceback in test > shows error message that "removal of segment will disconnect topology", > but this patch only swap order of replica names in segment name. I would > expect that you should get different error, something like segment does > not exist. Which I do get in jenkins job N 37: "segment not found" In fact, the error in the issue is unrelated to the fix, you are right. To tell the truth, I just put a random error from one of the jenkins topology testruns into the issue. This particular error message was caused by a previous replica installation failure, which resulted in existing only one segment instead of three: master <-> replica1 instead of: master <-> replica1, master <-> replica2 replica1 <-> replica2 In fact the patch supplied fixes 2 tests at once: The first test tries to remove the unexisting segment master <-> replica2 and fails, the second test expects the line topology master <-> replica1 <-> replica2. It removes the connection between replica1 and replica2, expects the operation to fail but it does not because the connection between master and replica2 exists the output from the testrun with the patch applied: -bash-4.3$ ipa-run-tests test_integration/test_topology.py --pdb WARNING: Couldn't write lextab module 'pycparser.lextab'. [Errno 13] Permission denied: 'lextab.py' WARNING: yacc table file version is out of date WARNING: Couldn't create 'pycparser.yacctab'. [Errno 13] Permission denied: 'yacctab.py' ==================================================================================== test session starts ===================================================================================== platform linux2 -- Python 2.7.11, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini plugins: sourceorder-0.5, multihost-1.0 collected 3 items test_integration/test_topology.py ... ================================================================================ 3 passed in 2156.82 seconds ================================================================================= > > Martin^2 > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Fri Aug 12 14:05:16 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Aug 2016 16:05:16 +0200 Subject: [Freeipa-devel] [Test][patch-0058] Fixed topology tests failures in CI In-Reply-To: <57ADD39F.8050409@redhat.com> References: <57AB735A.3000101@redhat.com> <57ADD39F.8050409@redhat.com> Message-ID: <5beb66d0-62d4-1940-79be-4bcf16a140aa@redhat.com> On 12.08.2016 15:48, Oleg Fayans wrote: > Hi Martin, > > > > On 08/11/2016 10:05 AM, Martin Basti wrote: >> >> >> On 10.08.2016 20:32, Oleg Fayans wrote: >>> >>> >>> >> Hello, >> >> before we jump into fixing tests, my question is: Was this planned >> change and not reflected by test, or switched values are unwanted side >> effect and thus bug for us? > > That's a marvelous question! The test used to pass, which means that > at some point the convention of naming the segments must have changed. > Is it a bug? I do not think so: the feature still works as expected. Ludwig, do you know details about this change, why positions of server names are different than used to be in topology name? > >> >> Ticket contains almost no info, except a traceback and it says nothing. >> Commit message says at least something. >> >> I'm not sure if this patch fixes that ticket, because traceback in test >> shows error message that "removal of segment will disconnect topology", >> but this patch only swap order of replica names in segment name. I would >> expect that you should get different error, something like segment does >> not exist. > Which I do get in jenkins job N 37: "segment not found" > > In fact, the error in the issue is unrelated to the fix, you are right. > To tell the truth, I just put a random error from one of the jenkins > topology testruns into the issue. This is very good way how to report tickets: * nobody knows what happened * nobody can search in current tickets, what is wrong without proper description * developers cannot investigate issue, because there is even no name of exact test in ticket, no steps to reproduce, nothing * without proper tickets it is hard to backport patches correctly, if patch fixes different issue than is reported I'm closing ticket as invalid, please follow http://www.chiark.greenend.org.uk/~sgtatham/bugs.html and file a new proper ticket. > This particular error message was caused by a previous replica > installation failure, which resulted in existing only one segment > instead of three: > master <-> replica1 > instead of: > master <-> replica1, > master <-> replica2 > replica1 <-> replica2 > > In fact the patch supplied fixes 2 tests at once: > The first test tries to remove the unexisting segment master <-> > replica2 and fails, the second test expects the line topology > master <-> replica1 <-> replica2. > It removes the connection between replica1 and replica2, expects the > operation to fail but it does not because the connection between > master and replica2 exists > > the output from the testrun with the patch applied: > > > -bash-4.3$ ipa-run-tests test_integration/test_topology.py --pdb > WARNING: Couldn't write lextab module 'pycparser.lextab'. [Errno 13] > Permission denied: 'lextab.py' > WARNING: yacc table file version is out of date > WARNING: Couldn't create 'pycparser.yacctab'. [Errno 13] Permission > denied: 'yacctab.py' > ==================================================================================== > test session starts > ===================================================================================== > platform linux2 -- Python 2.7.11, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 > rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini > plugins: sourceorder-0.5, multihost-1.0 > collected 3 items > > test_integration/test_topology.py ... > > ================================================================================ > 3 passed in 2156.82 seconds > ================================================================================= > I don't care about test output until there is no valid description of problem, fixing test may just cover real issue. Martin^2 >> >> Martin^2 >> >> > From pspacek at redhat.com Fri Aug 12 15:10:51 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Aug 2016 17:10:51 +0200 Subject: [Freeipa-devel] [PATCH 0158] DNS: allow to add forward zone to already broken sub-domain Message-ID: Hello, DNS: allow to add forward zone to already broken sub-domain Errors during DNS resolution might indicate that forwarder is the necessary configuration which is missing. Now we disallow adding a forwarder only if the zone is normally resolvable without the forwarder. https://fedorahosted.org/freeipa/ticket/6062 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0158-DNS-allow-to-add-forward-zone-to-already-broken-sub-.patch Type: text/x-patch Size: 1131 bytes Desc: not available URL: From pspacek at redhat.com Fri Aug 12 16:48:44 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Aug 2016 18:48:44 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: References: Message-ID: On 11.8.2016 12:34, Stanislav Laznicka wrote: > Hello, > > I updated the design of the Time-Based HBAC Policies according to the > discussion we led here earlier. Please check the design page > http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest > changes are in the Implementation and Feature Management sections. I also > added a short How to Use section. Nice page! On the high level it all makes sense. ad LDAP schema ============== 1) Why accessTime attribute is MAY in ipaTimeRule object class? Does it make sense to have the object without accessTime? I do not think so. Also, it could be good to add description attribute to the object class and incorporate it into commands (including find). 2) Besides all this, I spent few minutes in dark history of IPA. The accessTime attribute was introduced back in 2009 in commit "55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for IPAv2". The commit does not contain any reasoning for the change but I can see that the attribute is already used as MAY in old object classes ipaHBACRule and ipaSELinuxUserMap. Is any of these a problem? Why is it even in ipaSELinuxUserMap object class? Commit 55512dc938eb4a9a6655e473beab587e340af55c does not mention any reason for doing so. I cannot see any other problem so the low-level stuff is good and can be implemented. ad User interface ================= We need to polish the user interface so it really usable. At least the web interface should contain some shortcuts. E.g. when I'm adding a new HBAC rule, the "time" section should contain also "something" to immediately add new time rule so I do not need to go to time rules first and then go back to HBAC page. Similarly, dialog for rule modification should allow to easily change all the values, warn if time rules is shared, and also have an easy way to 'disconnect' the time rule, i.e. make a copy of it and edit only the new copy (instead of the shared original). All these are user interface things not affecting the low-level stuff. Maybe you should sat down with some UX designer, talk about these cases and draw some hand-made pictures. I do not believe that this will require any changes in schema so you can polish SSSD and framework implementation in meantime. > On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI > functionality (except for the creation of iCalendar strings from options) for > better illustration of the design. > > https://github.com/stlaz/freeipa/tree/timerules_2 Honestly I did not look at the code today :-) Overall, I'm glad to see current proposal. After so many iteration, we reached something which does not have any glaring problem :-) -- Petr^2 Spacek From pspacek at redhat.com Fri Aug 12 16:57:26 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Aug 2016 18:57:26 +0200 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> Message-ID: <7d7647ba-d9b0-6be8-18a6-5dbcf178c68c@redhat.com> On 12.8.2016 11:33, Jan Cholasta wrote: > On 4.8.2016 18:18, Petr Vobornik wrote: >> On 07/22/2016 07:13 AM, Fraser Tweedale wrote: >>> On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 14.7.2016 13:44, Fraser Tweedale wrote: >>>>> Hi all, >>>>> >>>>> The attached patch includes SANs in cert-show output. If you have >>>>> certs with esoteric altnames (especially any that are more than just >>>>> ASN.1 string types), please test with those certs. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6022 >>>> >>>> I think it would be better to have a separate attribute for each supported >>>> SAN type rather than cramming everything into subject_alt_name. That way if >>>> you care only about a single specific type you won't have to go through all >>>> the values and parse them. Also it would allow you to use param types >>>> appropriate to the SAN types (DNSNameParam for DNS names, Principal for >>>> principal names, etc.) >>>> >>>> Nitpick: please don't mix moving existing stuff and adding new stuff in a >>>> single patch. >>>> >>> Updated patches attached. >>> >>> Patches 0092..0094 are refactors and bugfixes. >>> Patch 0090-2 is the main feature (depends on 0092..0094). >>> >>> Thanks, >>> Fraser >>> >> >> bump for review > > Patch 0092: ACK > > Patch 0093: ACK > > Patch 0094: ACK > > Patch 0090: > > 1) Generic otherNames (san_other) do not work correctly. The OID is not > included in the value and names with complex type other than KerberosPrincipal > are not parsed correctly. The value should include the OID and DER blob of the > name. > > 2) With --all, san_other should be included in the result for all otherNames, > even the known ones, to provide (limited) forward compatibility. > > 3) Do we have to support *all* the name types? I mean we could, for the sake > of completeness, but it might be easier to just keep the few ones we actually > care about (email, DNS name, principal name, UPN and directory name in your > patch 0095). As far as I remember this reasoning usually comes back to bite us into butt. - "Implement only this subset, nobody else needs the other the of ... (whatever, e.g. DNS record type)." - "Yes my lord." Two months later: - "We need to support for XYZ. It was (already) late yesterday!" :-) Petr^2 Spacek > > 4) > > + obj.setdefault(attr_name, []).append(unicode(name)) > > The value should not (always) be unicode, but of the type declared by the > param (unicode or ipapython.kerberos.Principal or ipapython.dnsutil.DNSName). From pspacek at redhat.com Fri Aug 12 16:58:54 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Aug 2016 18:58:54 +0200 Subject: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts In-Reply-To: <256010841.13930537.1470754537126.JavaMail.zimbra@redhat.com> References: <256010841.13930537.1470754537126.JavaMail.zimbra@redhat.com> Message-ID: On 9.8.2016 16:55, Ganna Kaihorodova wrote: > Hello! > > Domain level 0 doesn't allow to create replica file on CA master, testcase was skipped with Domain level 0 You mean on CA-less master, right? Petr^2 Spacek > https://fedorahosted.org/freeipa/ticket/6134 From mharmsen at redhat.com Fri Aug 12 17:11:15 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 12 Aug 2016 11:11:15 -0600 Subject: [Freeipa-devel] Updated External EPEL CentOS 7 COPR builds are now available . . . Message-ID: <9ae13aa7-d518-ad26-e1e8-f384a45076e0@redhat.com> An updated external EPEL CentOS 7 COPR repo is now available which contains the latest Dogtag 10.3.3-5, tomcatjss, and jss builds: * https://copr.fedorainfracloud.org/coprs/g/pki/10.3.3/repo/epel-7/group_pki-10.3.3-epel-7.repo [group_pki-10.3.3] name=Copr repo for 10.3.3 owned by @pki baseurl=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.3/epel-7-$basearch/ skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.3/pubkey.gpg enabled=1 enabled_metadata=1 -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Aug 12 18:00:02 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Aug 2016 20:00:02 +0200 Subject: [Freeipa-devel] [PATCH 0159] Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin Message-ID: Hello, this is the last patch necessary to get all test_xmlrpc/test_dns_plugin tests to pass! (I hope :-) Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin Class test_forward_zones in ipatests/test_xmlrpc/test_dns_plugin was using DNS zone 'fwzone2.test.' and expected to get warning 'Forwarding policy conflicts with some automatic empty zones.' (aka 'DNSForwardPolicyConflictWithEmptyZone'). This does not make sense because 'test.' zone is not listed in IANA registry 'Locally-Served DNS Zones': http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml To fix this I simply removed the warning from set of expected results. https://fedorahosted.org/freeipa/ticket/6213 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0159-Tests-fix-test_forward_zones-in-test_xmlrpc-test_dns.patch Type: text/x-patch Size: 2017 bytes Desc: not available URL: From simo at redhat.com Sun Aug 14 08:59:56 2016 From: simo at redhat.com (Simo Sorce) Date: Sun, 14 Aug 2016 04:59:56 -0400 Subject: [Freeipa-devel] [PATCHES] Coverity fixes In-Reply-To: <1ce4148c-8b9e-88c9-e612-6b64a0f697f6@redhat.com> References: <1469440019.18067.66.camel@redhat.com> <6dcfcd32-05e3-d36c-484a-bb074373af4c@redhat.com> <20160805121337.GG6891@10.4.128.1> <1ce4148c-8b9e-88c9-e612-6b64a0f697f6@redhat.com> Message-ID: <1471165196.3492.10.camel@redhat.com> On Thu, 2016-08-11 at 14:51 +0200, Martin Basti wrote: > > On 05.08.2016 14:13, Lukas Slebodnik wrote: > > On (05/08/16 12:43), Petr Vobornik wrote: > >> On 07/28/2016 01:01 PM, Martin Basti wrote: > >>> > >>> On 25.07.2016 11:46, Simo Sorce wrote: > >>>> The attached patches fix some minor issues found by coverity, and pull > >>>> in other fixes released by the asn1c project. > >>>> > >>>> Simo. > >>>> > >>>> > >>>> > >>> I cannot build RPMS with this patch, is there any missing build dependency? > >>> > >>> /bin/sh ./libtool --tag=CC --mode=link gcc -Wall -Wshadow > >>> -Wstrict-prototypes -Wpointer-arith -Wcast-align > >>> -Werror-implicit-function-declaration -O2 -g -pipe -Wall > >>> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > >>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall > >>> -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare > >>> -Wno-missing-field-initializers -Wl,-z,relro > >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o > >>> ipa-client-common.o ipa_krb5.o ../asn1/libipaasn1.la -lkrb5 -lk5crypto -lcom_err > >>> -llber -lldap -lsasl2 -lpopt -lini_config -lbasicobjects -lref_array > >>> -lcollection -lini_config -lini_config > >>> libtool: link: gcc -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith > >>> -Wcast-align -Werror-implicit-function-declaration -O2 -g -pipe -Wall > >>> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > >>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall > >>> -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare > >>> -Wno-missing-field-initializers -Wl,-z -Wl,relro > >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o > >>> ipa-client-common.o ipa_krb5.o ../asn1/.libs/libipaasn1.a -lkrb5 -lk5crypto > >>> -lcom_err -llber -lldap -lsasl2 -lpopt -lbasicobjects -lref_array -lcollection > >>> -lini_config > >>> ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_decode_uper': > >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:897: > >>> undefined reference to `uper_open_type_get' > >>> ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_encode_uper': > >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:982: > >>> undefined reference to `uper_open_type_put' > >>> ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function > >>> `SEQUENCE_handle_extensions': > >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1285: > >>> undefined reference to `uper_open_type_put' > >>> ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function `SEQUENCE_decode_uper': > >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1187: > >>> undefined reference to `uper_open_type_get' > >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1203: > >>> undefined reference to `uper_open_type_skip' > >>> collect2: error: ld returned 1 exit status > >>> > >>> Martin^2 > >>> > >> Bumping. Was it temporary issue or issue in the patch? > >> > > I could not see such error. > > However, these patches would be good to test with coverity. > > We need to use fedora rawhide for testing due to BuildRequires > > in freeipa.spec. But C-part of freeIPA cannot be compiled on rawhide > > due to new samba (4.5). Patches are already on the list. > > > > LS > > > > Lukas helped me to fix error I reported before (missing entries in > Makefile.am), so I run covscan and I get bunch of new errors. > > Question is, do we want push autogenerated code? Yes we definitely want it pushed, so covscan can look at it and we can commit fixes before the upstream project (which is very slow) takes them in. Once these errors crop up in our covscan report I will take another pass at fixing the real ones and ignoring false positives. Simo. > > Error: FORWARD_NULL (CWE-476): [#def1] > freeipa-4.4.0/asn1/asn1c/INTEGER.c:463: assign_zero: Assigning: > "dec_value_start" = "NULL". > freeipa-4.4.0/asn1/asn1c/INTEGER.c:488: var_deref_model: Passing null > pointer "dec_value_start" to "asn_strtol_lim", which dereferences it. > freeipa-4.4.0/asn1/asn1c/INTEGER.c:975:2: deref_parm: Directly > dereferencing parameter "str". > # 973| if(str >= *end) return ASN_STRTOL_ERROR_INVAL; > # 974| > # 975|-> switch(*str) { > # 976| case '-': > # 977| last_digit_max++; > > Error: MISSING_BREAK (CWE-484): [#def2] > freeipa-4.4.0/asn1/asn1c/INTEGER.c:976: unterminated_case: The case for > value "'-'" is not terminated by a 'break' statement. > freeipa-4.4.0/asn1/asn1c/INTEGER.c:979: fallthrough: The above case > falls through to this one. > # 977| last_digit_max++; > # 978| sign = -1; > # 979|-> case '+': > # 980| str++; > # 981| if(str >= *end) { > > Error: NEGATIVE_RETURNS (CWE-394): [#def3] > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:381: var_tested_neg: Variable > "tlv_len" tests negative. > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:391: var_assign: Assigning: > signed variable "sel->left" = "tlv_len". > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:247: var_assign: Assigning: > unsigned variable "Left" = "sel->left". > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:275: negative_returns: "Left" is > passed to a parameter that cannot be negative. > freeipa-4.4.0/asn1/asn1c/ber_tlv_tag.c:33:2: parm_loop_bound: Using > unsigned parameter "size" in a loop exit test. > # 273| } > # 274| > # 275|-> tl = ber_fetch_tag(buf_ptr, Left, &tlv_tag); > # 276| ASN_DEBUG("fetch tag(size=%ld,L=%ld), %sstack, > left=%ld, wn=%ld, tl=%ld", > # 277| (long)size, (long)Left, sel?"":"!", > > Error: FORWARD_NULL (CWE-476): [#def4] > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:583: var_compare_op: Comparing > "st->buf" to null implies that "st->buf" might be null. > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:591: alias_transfer: Assigning: > "buf" = "st->buf". > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:601: var_deref_op: Dereferencing > null pointer "buf". > # 599| p = scratch; > # 600| } > # 601|-> *p++ = h2c[(*buf >> 4) & 0x0F]; > # 602| *p++ = h2c[*buf & 0x0F]; > # 603| } > > Error: FORWARD_NULL (CWE-476): [#def5] > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:583: var_compare_op: Comparing > "st->buf" to null implies that "st->buf" might be null. > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:591: alias_transfer: Assigning: > "buf" = "st->buf". > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:615: var_deref_op: Dereferencing > null pointer "buf". > # 613| _i_ASN_TEXT_INDENT(1, ilevel); > # 614| } > # 615|-> *p++ = h2c[(*buf >> 4) & 0x0F]; > # 616| *p++ = h2c[*buf & 0x0F]; > # 617| *p++ = 0x20; > > Error: FORWARD_NULL (CWE-476): [#def6] > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:739: var_compare_op: Comparing > "st->buf" to null implies that "st->buf" might be null. > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:742: alias_transfer: Assigning: > "buf" = "st->buf". > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:745: var_deref_op: Dereferencing > null pointer "buf". > # 743| end = buf + st->size; > # 744| for(ss = buf; buf < end; buf++) { > # 745|-> unsigned int ch = *buf; > # 746| int s_len; /* Special encoding sequence length */ > # 747| > > Error: FORWARD_NULL (CWE-476): [#def7] > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1659: var_compare_op: Comparing > "st->buf" to null implies that "st->buf" might be null. > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1665: alias_transfer: Assigning: > "buf" = "st->buf". > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1674: var_deref_op: > Dereferencing null pointer "buf". > # 1672| p = scratch; > # 1673| } > # 1674|-> *p++ = h2c[(*buf >> 4) & 0x0F]; > # 1675| *p++ = h2c[*buf & 0x0F]; > # 1676| *p++ = 0x20; > > Error: REVERSE_INULL (CWE-476): [#def8] > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1706: deref_ptr: Directly > dereferencing pointer "td". > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1713: check_after_deref: > Null-checking "td" suggests that it may be null, but it has already been > dereferenced on all paths leading to the check. > # 1711| struct _stack *stck; > # 1712| > # 1713|-> if(!td || !st) > # 1714| return; > # 1715| > > Error: DEADCODE (CWE-561): [#def9] > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:40: assignment: Assigning: > "len" = "0L". > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:44: cond_at_least: Condition > "len < 0L", taking false branch. Now the value of "len" is at least 0. > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:54: assignment: Assigning: > "lenplusepsilon" = "(size_t)len + 1024UL". > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:63: at_least: At condition > "lenplusepsilon < 0L", the value of "lenplusepsilon" must be at least 1024. > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:63: dead_error_condition: The > condition "lenplusepsilon < 0L" cannot be true. > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:65: dead_error_line: Execution > cannot reach this statement: "return -1L;". > # 63| if(lenplusepsilon < 0) { > # 64| /* Too large length value */ > # 65|-> return -1; > # 66| } > # 67| > > Error: REVERSE_INULL (CWE-476): [#def10] > freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:1034: deref_ptr: Directly > dereferencing pointer "td". > freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:1037: check_after_deref: > Null-checking "td" suggests that it may be null, but it has already been > dereferenced on all paths leading to the check. > # 1035| int present; > # 1036| > # 1037|-> if(!td || !ptr) > # 1038| return; > # 1039| > > Error: RESOURCE_LEAK (CWE-772): [#def11] > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1147: alloc_fn: Storage is > returned from allocation function "malloc". > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1147: var_assign: Assigning: > "epres" = storage returned from "malloc(bmlength + 15L >> 3)". > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1151: noescape: Resource > "epres" is not freed or pointed-to in "per_get_many_bits". > freeipa-4.4.0/asn1/asn1c/per_support.c:123:48: noescape: > "per_get_many_bits(asn_per_data_t *, uint8_t *, int, int)" does not free > or save its parameter "dst". > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1152: leaked_storage: > Variable "epres" going out of scope leaks the storage it points to. > # 1150| /* Get the extensions map */ > # 1151| if(per_get_many_bits(pd, epres, 0, bmlength)) > # 1152|-> _ASN_DECODE_STARVED; > # 1153| > # 1154| memset(&epmd, 0, sizeof(epmd)); > > Error: CHECKED_RETURN (CWE-252): [#def12] > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1320: check_return: Calling > "per_put_few_bits" without checking return value (as is done elsewhere > 23 out of 28 times). > freeipa-4.4.0/asn1/asn1c/INTEGER.c:724: example_checked: Example 1: > "per_put_few_bits(po, inext, 1)" has its value checked in > "per_put_few_bits(po, inext, 1)". > freeipa-4.4.0/asn1/asn1c/NativeEnumerated.c:180: example_checked: > Example 2: "per_put_few_bits(po, inext, 1)" has its value checked in > "per_put_few_bits(po, inext, 1)". > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1307: example_checked: Example > 3: "per_put_few_bits(po, ch, unit_bits)" has its value checked in > "per_put_few_bits(po, ch, unit_bits)". > freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:949: example_checked: Example > 4: "per_put_few_bits(po, 1U, 1)" has its value checked in > "per_put_few_bits(po, 1U, 1)". > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1282: example_checked: > Example 5: "per_put_few_bits(po1, present, 1)" has its value checked in > "per_put_few_bits(po1, present, 1)". > # 1318| if(specs->ext_before >= 0) { > # 1319| n_extensions = SEQUENCE_handle_extensions(td, sptr, 0, 0); > # 1320|-> per_put_few_bits(po, n_extensions ? 1 : 0, 1); > # 1321| } else { > # 1322| n_extensions = 0; /* There are no extensions to > encode */ > > Error: DEADCODE (CWE-561): [#def13] > freeipa-4.4.0/asn1/asn1c/per_encoder.c:126: cond_notnull: Condition > "td", taking true branch. Now the value of "td" is not "NULL". > freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: notnull: At condition "td", > the value of "td" cannot be "NULL". > freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: dead_error_condition: The > condition "td" must be true. > freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: dead_error_line: Execution > cannot reach the expression """" inside this statement: > "ASN_DEBUG("Failed to encode...". > # 144| > # 145| if(_uper_encode_flush_outp(&po)) > # 146|-> _ASN_ENCODE_FAILED; > # 147| } > # 148| > > Error: DEADCODE (CWE-561): [#def14] > freeipa-4.4.0/asn1/asn1c/per_opentype.c:176: assignment: Assigning: > "padding" = "pd->moved % 8UL". > freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: between: At condition > "padding > 7L", the value of "padding" must be between 1 and 7. > freeipa-4.4.0/asn1/asn1c/per_opentype.c:177: cond_cannot_single: > Condition "padding", taking true branch. Now the value of "padding" > cannot be equal to 0. > freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: cannot_single: At condition > "padding > 7L", the value of "padding" cannot be equal to 0. > freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: dead_error_condition: The > condition "padding > 7L" cannot be true. > freeipa-4.4.0/asn1/asn1c/per_opentype.c:180: dead_error_begin: Execution > cannot reach this statement: "ASN_DEBUG("Too large paddin...". > # 178| int32_t pvalue; > # 179| if(padding > 7) { > # 180|-> ASN_DEBUG("Too large padding %d in open type", > # 181| (int)padding); > # 182| rv.code = RC_FAIL; > > Error: OVERRUN (CWE-119): [#def15] > freeipa-4.4.0/asn1/asn1c/per_support.c:14: assignment: Assigning: "n" = > "(n + 1) % 2". The value of "n" is now between 0 and 1 (inclusive). > freeipa-4.4.0/asn1/asn1c/per_support.c:15: overrun-buffer-arg: Calling > "snprintf" with "buf[n]" and "64UL" is suspicious because the function > call may access "buf" at byte "n * sizeof (char [32]) + 63UL". [Note: > The source code implementation of the function has been overridden by a > builtin model.] > # 13| static int n; > # 14| n = (n+1) % 2; > # 15|-> snprintf(buf[n], sizeof(buf), > # 16| "{m=%ld span %+ld[%d..%d] (%d)}", > # 17| (long)pd->moved, > > Error: FORWARD_NULL (CWE-476): [#def16] > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1513: var_compare_op: Comparing > "st->buf" to null implies that "st->buf" might be null. > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1618: alias_transfer: Assigning: > "buf" = "st->buf". > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1631: var_deref_model: Passing > null pointer "buf" to "per_put_many_bits", which dereferences it. > freeipa-4.4.0/asn1/asn1c/per_support.c:419:4: deref_parm: Directly > dereferencing parameter "src". > # 417| > # 418| if(nbits >= 24) { > # 419|-> value = (src[0] << 16) | (src[1] << 8) | src[2]; > # 420| src += 3; > # 421| nbits -= 24; -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Mon Aug 15 05:48:22 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 15 Aug 2016 07:48:22 +0200 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: <7d7647ba-d9b0-6be8-18a6-5dbcf178c68c@redhat.com> References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> <7d7647ba-d9b0-6be8-18a6-5dbcf178c68c@redhat.com> Message-ID: <7d3265a6-defe-d45c-9491-26d8ec4b3927@redhat.com> On 12.8.2016 18:57, Petr Spacek wrote: > On 12.8.2016 11:33, Jan Cholasta wrote: >> On 4.8.2016 18:18, Petr Vobornik wrote: >>> On 07/22/2016 07:13 AM, Fraser Tweedale wrote: >>>> On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 14.7.2016 13:44, Fraser Tweedale wrote: >>>>>> Hi all, >>>>>> >>>>>> The attached patch includes SANs in cert-show output. If you have >>>>>> certs with esoteric altnames (especially any that are more than just >>>>>> ASN.1 string types), please test with those certs. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6022 >>>>> >>>>> I think it would be better to have a separate attribute for each supported >>>>> SAN type rather than cramming everything into subject_alt_name. That way if >>>>> you care only about a single specific type you won't have to go through all >>>>> the values and parse them. Also it would allow you to use param types >>>>> appropriate to the SAN types (DNSNameParam for DNS names, Principal for >>>>> principal names, etc.) >>>>> >>>>> Nitpick: please don't mix moving existing stuff and adding new stuff in a >>>>> single patch. >>>>> >>>> Updated patches attached. >>>> >>>> Patches 0092..0094 are refactors and bugfixes. >>>> Patch 0090-2 is the main feature (depends on 0092..0094). >>>> >>>> Thanks, >>>> Fraser >>>> >>> >>> bump for review >> >> Patch 0092: ACK >> >> Patch 0093: ACK >> >> Patch 0094: ACK >> >> Patch 0090: >> >> 1) Generic otherNames (san_other) do not work correctly. The OID is not >> included in the value and names with complex type other than KerberosPrincipal >> are not parsed correctly. The value should include the OID and DER blob of the >> name. >> >> 2) With --all, san_other should be included in the result for all otherNames, >> even the known ones, to provide (limited) forward compatibility. >> >> 3) Do we have to support *all* the name types? I mean we could, for the sake >> of completeness, but it might be easier to just keep the few ones we actually >> care about (email, DNS name, principal name, UPN and directory name in your >> patch 0095). > > As far as I remember this reasoning usually comes back to bite us into butt. > > - "Implement only this subset, nobody else needs the other the of ... > (whatever, e.g. DNS record type)." > - "Yes my lord." > > Two months later: > > - "We need to support for XYZ. It was (already) late yesterday!" > > :-) Care to give a concrete example of when this actually happened? Because IIRC this happened once or twice, not "usually". Anyway, I'm fine with whatever, my point was that additional effort needs to be put in to support "everything" and even then, we wouldn't actually support everything (two months later: "we need to support extension XYZ!"). (FWIW, I think it would be more useful to add support for Basic constraints rather than X.400 SANs.) > > Petr^2 Spacek > >> >> 4) >> >> + obj.setdefault(attr_name, []).append(unicode(name)) >> >> The value should not (always) be unicode, but of the type declared by the >> param (unicode or ipapython.kerberos.Principal or ipapython.dnsutil.DNSName). > -- Jan Cholasta From jcholast at redhat.com Mon Aug 15 06:19:33 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 15 Aug 2016 08:19:33 +0200 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <20160809144716.GA23927@dhcp-40-8.bne.redhat.com> References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> <885c4c72-6e8a-4220-b25e-f577612368d2@redhat.com> <20160809144716.GA23927@dhcp-40-8.bne.redhat.com> Message-ID: On 9.8.2016 16:47, Fraser Tweedale wrote: > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: >> On 8.8.2016 09:06, Fraser Tweedale wrote: >>> On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 8.8.2016 06:34, Fraser Tweedale wrote: >>>>> Please review the attached patch with adds --certificate-out and >>>>> --certificate-chain-out options to `ca-show' command. >>>>> >>>>> Note that --certificate-chain-out currently writes a bogus file due >>>>> to a bug in Dogtag that will be fixed in this week's build. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6178 >>>> >>>> 1) The client-side *-out options should be defined on the client side, not >>>> on the server side. >>>> >>> Will option defined on client side be propagated to, and observable >>> in the ipaserver plugin? The ipaserver plugin needs to observe that >>> *-out has been requested and executes additional command(s) on that >>> basis. >> >> Is there a reason not to *always* return the certs? >> > We hit Dogtag to retrieve them. I don't think that's an issue in a -show command. > >>> >>>> >>>> 2) I don't think there should be additional information included in summary >>>> (and it definitely should not be multi-line). I would rather inform the user >>>> via an error message when unable to write the files. >>>> >>> I was just following the pattern of other commands that write certs, >>> profile config, etc. Apart from consistency with other commands I >>> agree that there is no need to have it. So I will remove it. >>> >>>> If you think there is an actual value in informing the user about >>>> successfully writing the files, please use ipalib.messages for the job. >>>> >>>> >>>> 3) IMO a better format for the certificate chain than PKCS#7 would be >>>> concatenated PEM, as that's the most commonly used format in IPA (in >>>> installers, there are no cert chains in API commands ATM). >>>> >>> Sure, but the main use case isn't IPA. Other apps require PKCS #7 >>> or concatenated PEMs, but sometimes they must be concatenated >>> forward, and othertimes backwards. There is no one size fits all. >> >> True, which is exactly why I think we should at least be self-consistent and >> use concatenated PEM (and multi-value DER over the wire). >> > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept > header). > > If we want list-of-PEMs between server and client we have to convert > on the server. Do we have a good way of doing this without exec'ing > `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' > to do the conversion on the server? python-nss does not have PKCS7 > functions and I am not keen on adding a pyasn1 PKCS7 parser just for > the sake of pushing bits as list-of-PEMs. I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other. For example, if we added a call to retrieve external CA chain using certs from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to PKCS#7 if it was our cert chain format of choice. What we can avoid though is executing "openssl pkcs7" to do the conversion - we can use an approach similar to our DNSSEC code and use python-cffi to call libcrypto's PKCS#7 conversion routines instead. > > FWIW, man pages and code suggest that PKCS #7 is accepted in > installer, etc. True, but that's a relatively new feature (since 4.1) and the installer internally executes "openssl pkcs7" to convert PKCS #7 to list of certs :-) > >>> We can add an option to control the format later, but for now, >>> Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst >>> case is an admin has to invoke `openssl pkcs7' and concat the certs >>> themselves. >> >> AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, >> so I'm afraid the worst case would happen virtually always. >> > If you're OK with invoking OpenSSL on the client to convert PKCS #7 > to list-of-PEMs (similar to what is done in > ipapython.certdb.NSSDatabase) then we can have the client perform > the conversion. See above. > >>> >>>> >>>> 4) Over the wire, the certs should be DER-formatted, as that's the most >>>> common wire format in other API commands. >>>> >>> OK. >>> >>>> >>>> 5) What is the benefit in having the CA cert and the rest of the chain >>>> separate? For end-entity certs it makes sense to separate the cert from the >>>> CA chain, but for CA certs, you usually want the full chain, no? >>>> >>> If you want to anchor trust directly at a subca (e.g. restrict VPN >>> login to certs issued by VPN sub-CA) then you often just want the >>> cert. The chain option does subsume it, at cost of more work for >>> administrators with this use case. I think it makes sense to keep >>> both options. >> >> Does it? From what you described above, you either want just the sub-CA >> cert, or the full chain including the sub-CA cert, in which case it might >> make more sense to have a single --out option and a --chain flag. >> > How about --certificate-out which defaults to single cert, but does > chain (as list-of-PEMs) when --chain flag given. > > Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more > `--out' options. +1 > > Thanks, > Fraser > -- Jan Cholasta From mkosek at redhat.com Mon Aug 15 06:41:22 2016 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Aug 2016 08:41:22 +0200 Subject: [Freeipa-devel] [PATCH] 0078-82: webui tests: tests for new certificate widget In-Reply-To: References: <3e447bbe-fade-c5e5-2415-15ed7ae0b2ea@redhat.com> <7298654a-0ea9-8f42-dc24-f48f0dabeeb4@redhat.com> Message-ID: <35f1560f-1fd9-528e-db08-a9cbccae21c0@redhat.com> On 07/29/2016 03:00 PM, Pavel Vomacka wrote: > > > On 07/28/2016 08:16 AM, Lenka Doudova wrote: >> >> >> >> On 07/20/2016 04:51 PM, Pavel Vomacka wrote: >>> Please review attached patches, which add tests for new certificate widget in >>> WebUI. >>> >>> https://fedorahosted.org/freeipa/ticket/6064 >>> >>> >>> >> Hi, >> thanks for patches. >> Functionally ok, but you have lots of PEP8 errors in patches 78, 80, 81 and 82 >> -> NACK. >> Also in patch 82, method test_arbitrary_certificate, comment says user needs >> to have "arbitrary_cert" configured, but the property in config file is >> correctly "arbitrary_cert_path", so it's a bit misleading. >> >> Patch 79 is OK, ACK. >> >> Lenka >> >> > Thank you for review. Attaching patches which have fixed all pep8 erros. Bad > property of config file was also mentioned in patch 81. These are also fixed. It looks like these patches had wrong author set. Pavel, you may want to revisit your work environment management scripts :-) (I wonder if this is worth updating .mailmap to avoid wrong git shortlog) From ftweedal at redhat.com Mon Aug 15 07:15:16 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 15 Aug 2016 17:15:16 +1000 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> Message-ID: <20160815071516.GL23927@dhcp-40-8.bne.redhat.com> Thanks for reviews. Rebased and updated patches attached (and one new patch). No substantive changes to 92..94. Patch order is: 92-2, 93-2, 94-2, 98, 90-3 Other comments inline. Thanks, Fraser On Fri, Aug 12, 2016 at 11:33:28AM +0200, Jan Cholasta wrote: > Patch 0092: ACK > > Patch 0093: ACK > > Patch 0094: ACK > > Patch 0090: > > 1) Generic otherNames (san_other) do not work correctly. The OID is not > included in the value and names with complex type other than > KerberosPrincipal are not parsed correctly. The value should include the OID > and DER blob of the name. > Updated to use "OID:b64(DER)" as the attribute value. > 2) With --all, san_other should be included in the result for all > otherNames, even the known ones, to provide (limited) forward compatibility. > Done; when --all given, known otherName kinds are included in 'san_other' attribute in addition to their own attribute. > 3) Do we have to support *all* the name types? I mean we could, for the sake > of completeness, but it might be easier to just keep the few ones we > actually care about (email, DNS name, principal name, UPN and directory name > in your patch 0095). > Yeah, why not support them all? See also Petr's comments in other branch of thread. > 4) > > + obj.setdefault(attr_name, []).append(unicode(name)) > > The value should not (always) be unicode, but of the type declared by the > param (unicode or ipapython.kerberos.Principal or > ipapython.dnsutil.DNSName). > I now pass the value to the constructor of whatever type the parameter uses: attr_value = self.params[attr_name].type(name_formatted) obj.setdefault(attr_name, []).append(attr_value) -------------- next part -------------- From 17e5515ab0eeb92d87091eb00a26dcf358060dba Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 21 Jul 2016 16:27:49 +1000 Subject: [PATCH 92/94] Move GeneralName parsing code to ipalib.x509 GeneralName parsing code is primarily relevant to X.509. An upcoming change will add SAN parsing to the cert-show command, so first move the GeneralName parsing code from ipalib.pkcs10 to ipalib.x509. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/pkcs10.py | 93 ++----------------------------------- ipalib/x509.py | 114 +++++++++++++++++++++++++++++++++++++++++++++- ipaserver/plugins/cert.py | 8 ++-- 3 files changed, 120 insertions(+), 95 deletions(-) diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py index e340c1a2005ad781542a32a0a76753e80364dacf..158ebb3a25be2bd292f3883545fe8afe49b7be8c 100644 --- a/ipalib/pkcs10.py +++ b/ipalib/pkcs10.py @@ -22,9 +22,10 @@ from __future__ import print_function import sys import base64 import nss.nss as nss -from pyasn1.type import univ, char, namedtype, tag +from pyasn1.type import univ, namedtype, tag from pyasn1.codec.der import decoder import six +from ipalib import x509 if six.PY3: unicode = str @@ -32,11 +33,6 @@ if six.PY3: PEM = 0 DER = 1 -SAN_DNSNAME = 'DNS name' -SAN_RFC822NAME = 'RFC822 Name' -SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' -SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' - def get_subject(csr, datatype=PEM): """ Given a CSR return the subject value. @@ -72,78 +68,6 @@ def get_extensions(csr, datatype=PEM): return tuple(get_prefixed_oid_str(ext)[4:] for ext in request.extensions) -class _PrincipalName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('name-type', univ.Integer().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('name-string', univ.SequenceOf(char.GeneralString()).subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - ) - -class _KRB5PrincipalName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('realm', char.GeneralString().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('principalName', _PrincipalName().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - ) - -def _decode_krb5principalname(data): - principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0] - realm = (str(principal['realm']).replace('\\', '\\\\') - .replace('@', '\\@')) - name = principal['principalName']['name-string'] - name = '/'.join(str(n).replace('\\', '\\\\') - .replace('/', '\\/') - .replace('@', '\\@') for n in name) - name = '%s@%s' % (name, realm) - return name - -class _AnotherName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('type-id', univ.ObjectIdentifier()), - namedtype.NamedType('value', univ.Any().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - ) - -class _GeneralName(univ.Choice): - componentType = namedtype.NamedTypes( - namedtype.NamedType('otherName', _AnotherName().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('rfc822Name', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - namedtype.NamedType('dNSName', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2)) - ), - namedtype.NamedType('x400Address', univ.Sequence().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) - ), - namedtype.NamedType('directoryName', univ.Choice().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) - ), - namedtype.NamedType('ediPartyName', univ.Sequence().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 5)) - ), - namedtype.NamedType('uniformResourceIdentifier', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 6)) - ), - namedtype.NamedType('iPAddress', univ.OctetString().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 7)) - ), - namedtype.NamedType('registeredID', univ.ObjectIdentifier().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 8)) - ), - ) - -class _SubjectAltName(univ.SequenceOf): - componentType = _GeneralName() def get_subjectaltname(csr, datatype=PEM): """ @@ -159,19 +83,8 @@ def get_subjectaltname(csr, datatype=PEM): return None del request - nss_names = nss.x509_alt_name(extension.value, nss.AsObject) - asn1_names = decoder.decode(extension.value.data, - asn1Spec=_SubjectAltName())[0] - names = [] - for nss_name, asn1_name in zip(nss_names, asn1_names): - name_type = nss_name.type_string - if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: - name = _decode_krb5principalname(asn1_name['otherName']['value']) - else: - name = nss_name.name - names.append((name_type, name)) + return x509.decode_generalnames(extension.value) - return tuple(names) # Unfortunately, NSS can only parse the extension request attribute, so # we have to parse friendly name ourselves (see RFC 2986) diff --git a/ipalib/x509.py b/ipalib/x509.py index 82194922d151a1b0f2df03df3578ad45b43b71c9..15168de08240a84794efef409d022eaa983291c9 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -40,7 +40,7 @@ import re import nss.nss as nss from nss.error import NSPRError -from pyasn1.type import univ, namedtype, tag +from pyasn1.type import univ, char, namedtype, tag from pyasn1.codec.der import decoder, encoder import six @@ -63,6 +63,11 @@ EKU_EMAIL_PROTECTION = '1.3.6.1.5.5.7.3.4' EKU_ANY = '2.5.29.37.0' EKU_PLACEHOLDER = '1.3.6.1.4.1.3319.6.10.16' +SAN_DNSNAME = 'DNS name' +SAN_RFC822NAME = 'RFC822 Name' +SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' +SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' + _subject_base = None def subject_base(): @@ -374,6 +379,113 @@ def encode_ext_key_usage(ext_key_usage): eku = encoder.encode(eku) return _encode_extension('2.5.29.37', EKU_ANY not in ext_key_usage, eku) + +class _AnotherName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('type-id', univ.ObjectIdentifier()), + namedtype.NamedType('value', univ.Any().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + ) + + +class _GeneralName(univ.Choice): + componentType = namedtype.NamedTypes( + namedtype.NamedType('otherName', _AnotherName().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('rfc822Name', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + namedtype.NamedType('dNSName', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2)) + ), + namedtype.NamedType('x400Address', univ.Sequence().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) + ), + namedtype.NamedType('directoryName', univ.Choice().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) + ), + namedtype.NamedType('ediPartyName', univ.Sequence().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 5)) + ), + namedtype.NamedType('uniformResourceIdentifier', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 6)) + ), + namedtype.NamedType('iPAddress', univ.OctetString().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 7)) + ), + namedtype.NamedType('registeredID', univ.ObjectIdentifier().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 8)) + ), + ) + + +class _SubjectAltName(univ.SequenceOf): + componentType = _GeneralName() + + +class _PrincipalName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('name-type', univ.Integer().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('name-string', univ.SequenceOf(char.GeneralString()).subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + ) + + +class _KRB5PrincipalName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('realm', char.GeneralString().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('principalName', _PrincipalName().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + ) + + +def _decode_krb5principalname(data): + principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0] + realm = (str(principal['realm']).replace('\\', '\\\\') + .replace('@', '\\@')) + name = principal['principalName']['name-string'] + name = '/'.join(str(n).replace('\\', '\\\\') + .replace('/', '\\/') + .replace('@', '\\@') for n in name) + name = '%s@%s' % (name, realm) + return name + + +def decode_generalnames(secitem): + """ + Decode a GeneralNames object (this the data for the Subject + Alt Name and Issuer Alt Name extensions, among others). + + ``secitem`` + The input is the DER-encoded extension data, without the + OCTET STRING header, as an nss SecItem object. + + Return a list of tuples of name types (as string, suitable for + presentation) and names (as string, suitable for presentation). + + """ + nss_names = nss.x509_alt_name(secitem, repr_kind=nss.AsObject) + asn1_names = decoder.decode(secitem.data, asn1Spec=_SubjectAltName())[0] + names = [] + for nss_name, asn1_name in zip(nss_names, asn1_names): + name_type = nss_name.type_string + if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: + name = _decode_krb5principalname(asn1_name['otherName']['value']) + else: + name = nss_name.name + names.append((name_type, name)) + + return names + + if __name__ == '__main__': # this can be run with: # python ipalib/x509.py < /etc/ipa/ca.crt diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 06041d3083565e8d093b610473d6083111d406d2..85be2cf4daeb282b2c2ba866017c8e5745abda6d 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -535,7 +535,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): # Validate the subject alt name, if any for name_type, name in subjectaltname: - if name_type == pkcs10.SAN_DNSNAME: + if name_type == x509.SAN_DNSNAME: name = unicode(name) alt_principal_obj = None alt_principal_string = unicode(principal) @@ -566,13 +566,13 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "with subject alt name '%s'.") % name) if alt_principal_string is not None and not bypass_caacl: caacl_check(principal_type, principal, ca, profile_id) - elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, - pkcs10.SAN_OTHERNAME_UPN): + elif name_type in (x509.SAN_OTHERNAME_KRB5PRINCIPALNAME, + x509.SAN_OTHERNAME_UPN): if name != principal_string: raise errors.ACIError( info=_("Principal '%s' in subject alt name does not " "match requested principal") % name) - elif name_type == pkcs10.SAN_RFC822NAME: + elif name_type == x509.SAN_RFC822NAME: if principal_type == USER: if name not in principal_obj.get('mail', []): raise errors.ValidationError( -- 2.5.5 -------------- next part -------------- From 27a31d28a0af4a84545678f72ae86946dc9ebeaf Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 22 Jul 2016 12:05:13 +1000 Subject: [PATCH 93/94] x509: fix SAN directoryName parsing The subjectAltName extension parsing code in ipalib.x509 fails on directoryName values because the Choice structure is not endowed with an inner type. Implement the Name structure, whose inner type is a CHOICE { SEQUENCE OF RelativeDistinguishedName }, to resolve. Note that the structure still does not get fully parsed; only enough to recognise the SequenceOf tag and not fail. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/x509.py | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/ipalib/x509.py b/ipalib/x509.py index 15168de08240a84794efef409d022eaa983291c9..2dc67441c92686826dd24f00a5ad30566cd032da 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -196,6 +196,12 @@ def is_self_signed(certificate, datatype=PEM, dbdir=None): del nsscert return self_signed +class _Name(univ.Choice): + componentType = namedtype.NamedTypes( + namedtype.NamedType('rdnSequence', + univ.SequenceOf()), + ) + class _TBSCertificate(univ.Sequence): componentType = namedtype.NamedTypes( namedtype.NamedType( @@ -204,9 +210,9 @@ class _TBSCertificate(univ.Sequence): tag.tagClassContext, tag.tagFormatSimple, 0))), namedtype.NamedType('serialNumber', univ.Integer()), namedtype.NamedType('signature', univ.Sequence()), - namedtype.NamedType('issuer', univ.Sequence()), + namedtype.NamedType('issuer', _Name()), namedtype.NamedType('validity', univ.Sequence()), - namedtype.NamedType('subject', univ.Sequence()), + namedtype.NamedType('subject', _Name()), namedtype.NamedType('subjectPublicKeyInfo', univ.Sequence()), namedtype.OptionalNamedType( 'issuerUniquedID', @@ -403,7 +409,7 @@ class _GeneralName(univ.Choice): namedtype.NamedType('x400Address', univ.Sequence().subtype( implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) ), - namedtype.NamedType('directoryName', univ.Choice().subtype( + namedtype.NamedType('directoryName', _Name().subtype( implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) ), namedtype.NamedType('ediPartyName', univ.Sequence().subtype( -- 2.5.5 -------------- next part -------------- From 6e8dac22d4a985ce344c0d8583260cf5ceccbc1b Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 22 Jul 2016 12:11:59 +1000 Subject: [PATCH 94/94] x509: use NSS enums and OIDs to identify SAN types GeneralName parsing currently relies heavily on strings from NSS. Make the code hopefully less brittle by identifying GeneralName types by NSS enums and, for otherName, the name-type OID also. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/x509.py | 30 +++++++++++++++++++++++------- ipaserver/plugins/cert.py | 19 ++++++++++--------- 2 files changed, 33 insertions(+), 16 deletions(-) diff --git a/ipalib/x509.py b/ipalib/x509.py index 2dc67441c92686826dd24f00a5ad30566cd032da..541609fbc1a53a73eafcff2327e53a292c2d9a3c 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -33,6 +33,7 @@ from __future__ import print_function +import collections import os import sys import base64 @@ -63,10 +64,8 @@ EKU_EMAIL_PROTECTION = '1.3.6.1.5.5.7.3.4' EKU_ANY = '2.5.29.37.0' EKU_PLACEHOLDER = '1.3.6.1.4.1.3319.6.10.16' -SAN_DNSNAME = 'DNS name' -SAN_RFC822NAME = 'RFC822 Name' -SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' -SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' +SAN_UPN = '1.3.6.1.4.1.311.20.2.3' +SAN_KRB5PRINCIPALNAME = '1.3.6.1.5.2.2' _subject_base = None @@ -465,6 +464,10 @@ def _decode_krb5principalname(data): return name +GeneralNameInfo = collections.namedtuple( + 'GeneralNameInfo', ('type', 'desc', 'value')) + + def decode_generalnames(secitem): """ Decode a GeneralNames object (this the data for the Subject @@ -482,12 +485,25 @@ def decode_generalnames(secitem): asn1_names = decoder.decode(secitem.data, asn1Spec=_SubjectAltName())[0] names = [] for nss_name, asn1_name in zip(nss_names, asn1_names): - name_type = nss_name.type_string - if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: + # NOTE: we use the NSS enum to identify the name type. + # (For otherName we also tuple it up with the type-id OID). + # The enum does not correspond exactly to the ASN.1 tags. + # If we ever want to switch to using the true tag numbers, + # the expression to get the tag is: + # + # asn1_name.getComponent().getTagSet()[0].asTuple()[2] + # + if nss_name.type_enum == nss.certOtherName: + oid = str(asn1_name['otherName']['type-id']) + nametype = (nss_name.type_enum, oid) + else: + nametype = nss_name.type_enum + + if nametype == (nss.certOtherName, SAN_KRB5PRINCIPALNAME): name = _decode_krb5principalname(asn1_name['otherName']['value']) else: name = nss_name.name - names.append((name_type, name)) + names.append(GeneralNameInfo(nametype, nss_name.type_string, name)) return names diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 85be2cf4daeb282b2c2ba866017c8e5745abda6d..207f6964645254ebc417cab80634a68911ae0a08 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -534,8 +534,8 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "to the 'userCertificate' attribute of entry '%s'.") % dn) # Validate the subject alt name, if any - for name_type, name in subjectaltname: - if name_type == x509.SAN_DNSNAME: + for name_type, desc, name in subjectaltname: + if name_type == nss.certDNSName: name = unicode(name) alt_principal_obj = None alt_principal_string = unicode(principal) @@ -549,7 +549,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): raise errors.ValidationError( name='csr', error=_("subject alt name type %s is forbidden " - "for user principals") % name_type + "for user principals") % desc ) except errors.NotFound: # We don't want to issue any certificates referencing @@ -566,13 +566,15 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "with subject alt name '%s'.") % name) if alt_principal_string is not None and not bypass_caacl: caacl_check(principal_type, principal, ca, profile_id) - elif name_type in (x509.SAN_OTHERNAME_KRB5PRINCIPALNAME, - x509.SAN_OTHERNAME_UPN): + elif name_type in [ + (nss.certOtherName, x509.SAN_UPN), + (nss.certOtherName, x509.SAN_KRB5PRINCIPALNAME), + ]: if name != principal_string: raise errors.ACIError( info=_("Principal '%s' in subject alt name does not " "match requested principal") % name) - elif name_type == x509.SAN_RFC822NAME: + elif name_type == nss.certRFC822Name: if principal_type == USER: if name not in principal_obj.get('mail', []): raise errors.ValidationError( @@ -585,12 +587,11 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): raise errors.ValidationError( name='csr', error=_("subject alt name type %s is forbidden " - "for non-user principals") % name_type + "for non-user principals") % desc ) else: raise errors.ACIError( - info=_("Subject alt name type %s is forbidden") % - name_type) + info=_("Subject alt name type %s is forbidden") % desc) # Request the certificate result = self.Backend.ra.request_certificate( -- 2.5.5 -------------- next part -------------- From 9481e0436dc46b4668f1a45bd21f97c2096da142 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 15 Aug 2016 15:39:49 +1000 Subject: [PATCH] x509: include otherName DER value in GeneralNameInfo We want to include the whole DER value when we pretty-print unrecognised otherNames, so add a field to the GeneralNameInfo namedtuple and populate it for otherNames. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/x509.py | 13 +++++++++---- ipaserver/plugins/cert.py | 2 +- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/ipalib/x509.py b/ipalib/x509.py index 541609fbc1a53a73eafcff2327e53a292c2d9a3c..e986a97a58aafd3aeab08765a397edbf67c7841a 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -465,7 +465,7 @@ def _decode_krb5principalname(data): GeneralNameInfo = collections.namedtuple( - 'GeneralNameInfo', ('type', 'desc', 'value')) + 'GeneralNameInfo', ('type', 'desc', 'value', 'der_value')) def decode_generalnames(secitem): @@ -477,8 +477,9 @@ def decode_generalnames(secitem): The input is the DER-encoded extension data, without the OCTET STRING header, as an nss SecItem object. - Return a list of tuples of name types (as string, suitable for - presentation) and names (as string, suitable for presentation). + Return a list of ``GeneralNameInfo`` namedtuples. The + ``der_value`` field is set for otherNames, otherwise it is + ``None``. """ nss_names = nss.x509_alt_name(secitem, repr_kind=nss.AsObject) @@ -496,14 +497,18 @@ def decode_generalnames(secitem): if nss_name.type_enum == nss.certOtherName: oid = str(asn1_name['otherName']['type-id']) nametype = (nss_name.type_enum, oid) + der_value = asn1_name['otherName']['value'].asOctets() else: nametype = nss_name.type_enum + der_value = None if nametype == (nss.certOtherName, SAN_KRB5PRINCIPALNAME): name = _decode_krb5principalname(asn1_name['otherName']['value']) else: name = nss_name.name - names.append(GeneralNameInfo(nametype, nss_name.type_string, name)) + + gni = GeneralNameInfo(nametype, nss_name.type_string, name, der_value) + names.append(gni) return names diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 207f6964645254ebc417cab80634a68911ae0a08..30c708113942fca4d1f11aa1219367110e518309 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -534,7 +534,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "to the 'userCertificate' attribute of entry '%s'.") % dn) # Validate the subject alt name, if any - for name_type, desc, name in subjectaltname: + for name_type, desc, name, der_name in subjectaltname: if name_type == nss.certDNSName: name = unicode(name) alt_principal_obj = None -- 2.5.5 -------------- next part -------------- From 0706141a0457a90e58c94527c65d7f1ead87c719 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 14 Jul 2016 21:36:33 +1000 Subject: [PATCH] cert-show: show subject alternative names Enhance the cert-show command to return subject alternative name values. Fixes: https://fedorahosted.org/freeipa/ticket/6022 --- ipaserver/plugins/cert.py | 125 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 120 insertions(+), 5 deletions(-) diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 30c708113942fca4d1f11aa1219367110e518309..c42ba2de06df5d6204275fb9d31694268814a269 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -38,7 +38,7 @@ from ipalib import ngettext from ipalib.constants import IPA_CA_CN from ipalib.crud import Create, PKQuery, Retrieve, Search from ipalib.frontend import Method, Object -from ipalib.parameters import Bytes, DateTime, DNParam, Principal +from ipalib.parameters import Bytes, DateTime, DNParam, DNSNameParam, Principal from ipalib.plugable import Registry from .virtual import VirtualCommand from .baseldap import pkey_to_value @@ -49,6 +49,7 @@ from ipalib.request import context from ipalib import output from ipapython import kerberos from ipapython.dn import DN +from ipapython.ipa_log_manager import root_logger from ipaserver.plugins.service import normalize_principal, validate_realm if six.PY3: @@ -293,9 +294,74 @@ class BaseCertObject(Object): label=_('Serial number (hex)'), flags={'no_create', 'no_update', 'no_search'}, ), + Str( + 'san_rfc822name*', + label=_('Subject Alternative Name (Email)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + DNSNameParam( + 'san_dnsname*', + label=_('Subject Alternative Name (DNS)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_x400address*', + label=_('Subject Alternative Name (X.400 address)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_directoryname*', + label=_('Subject Alternative Name (Directory name)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_edipartyname*', + label=_('Subject Alternative Name (EDI Party name)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_uri*', + label=_('Subject Alternative Name (URI)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_ipaddress*', + label=_('Subject Alternative Name (IP Address)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_oid*', + label=_('Subject Alternative Name (OID)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Principal( + 'san_other_upn*', + label=_('Subject Alternative Name (UPN)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Principal( + 'san_other_kpn*', + label=_('Subject Alternative Name (Kerberos Principal)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_other*', + label=_('Subject Alternative Name (Other Name)'), + flags={'no_create', 'no_update', 'no_search'}, + ), ) - def _parse(self, obj): + def _parse(self, obj, generic_othernames): + """Extract certificate-specific data into a result object. + + ``obj`` + Result object containing certificate, into which extracted + data will be inserted. + ``generic_othernames`` + If ``True`` add recognised otherNames to the generic + ``san_other`` attribute as well as their own attribute. + + """ cert = x509.load_certificate(obj['certificate']) obj['subject'] = DN(unicode(cert.subject)) obj['issuer'] = DN(unicode(cert.issuer)) @@ -308,6 +374,55 @@ class BaseCertObject(Object): obj['serial_number'] = cert.serial_number obj['serial_number_hex'] = u'0x%X' % cert.serial_number + try: + ext_san = cert.get_extension(nss.SEC_OID_X509_SUBJECT_ALT_NAME) + general_names = x509.decode_generalnames(ext_san.value) + except KeyError: + general_names = [] + + for name_type, desc, name, der_name in general_names: + try: + self._add_san_attribute( + obj, generic_othernames, name_type, name, der_name) + except Exception as e: + # Invalid GeneralName (i.e. not a valid X.509 cert); + # don't fail but log something about it + root_logger.warning( + "Encountered bad GeneralName; skipping", exc_info=True) + + + def _add_san_attribute( + self, obj, generic_othernames, name_type, name, der_name): + name_type_map = { + nss.certRFC822Name: 'san_rfc822name', + nss.certDNSName: 'san_dnsname', + nss.certX400Address: 'san_x400address', + nss.certDirectoryName: 'san_directoryname', + nss.certEDIPartyName: 'san_edipartyname', + nss.certURI: 'san_uri', + nss.certIPAddress: 'san_ipaddress', + nss.certRegisterID: 'san_oid', + (nss.certOtherName, x509.SAN_UPN): 'san_other_upn', + (nss.certOtherName, x509.SAN_KRB5PRINCIPALNAME): 'san_other_kpn', + } + + attr_name = name_type_map.get(name_type, 'san_other') + + if attr_name != 'san_other': + name_formatted = name + else: + # display as "OID : b64(DER)" + name_formatted = u'{}:{}'.format( + name_type[1], base64.b64encode(der_name)) + attr_value = self.params[attr_name].type(name_formatted) + obj.setdefault(attr_name, []).append(attr_value) + + if generic_othernames and attr_name.startswith('san_other_'): + # recurse, faking the name type so that OID is still conveyed, + # but it won't be found in name_type_map + self._add_san_attribute( + obj, False, (None, name_type[1]), name, der_name) + class BaseCertMethod(Method): def get_options(self): @@ -597,7 +712,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): result = self.Backend.ra.request_certificate( csr, profile_id, ca_id, request_type=request_type) if not raw: - self.obj._parse(result) + self.obj._parse(result, all) result['request_id'] = int(result['request_id']) # Success? Then add it to the principal's entry @@ -775,7 +890,7 @@ class cert_show(Retrieve, CertMethod, VirtualCommand): if not raw: result['certificate'] = result['certificate'].replace('\r\n', '') - self.obj._parse(result) + self.obj._parse(result, all) result['revoked'] = ('revocation_reason' in result) if 'owner' in result: self.obj._fill_owners(result) @@ -1143,7 +1258,7 @@ class cert_find(Search, CertMethod): if 'certificate' in obj: obj['certificate'] = ( obj['certificate'].replace('\r\n', '')) - self.obj._parse(obj) + self.obj._parse(obj, all) if not all: del obj['certificate'] del obj['valid_not_before'] -- 2.5.5 From ofayans at redhat.com Mon Aug 15 07:24:18 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 15 Aug 2016 09:24:18 +0200 Subject: [Freeipa-devel] default debug_level of sssd Message-ID: <57B16E22.5030302@redhat.com> Hi all, Does anyone know what is the default debug_level for sssd daemon in ipa? We've found out that some tests (mainly basic-trust) generate huge volumes of sssd logs which we have to store. A quick glance into the logs show that these log every tiny bit of really low level information that we probably never gonna need. We'd like to tweak the tests to configure sssd for less logging, but I was unable to find info on default debug_level. The sssd configuration file does not explicitly specify it. Thanks! -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From abokovoy at redhat.com Mon Aug 15 07:40:05 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Aug 2016 10:40:05 +0300 Subject: [Freeipa-devel] default debug_level of sssd In-Reply-To: <57B16E22.5030302@redhat.com> References: <57B16E22.5030302@redhat.com> Message-ID: <20160815074005.3ynt6secwfsbyd2z@redhat.com> On Mon, 15 Aug 2016, Oleg Fayans wrote: >Hi all, > >Does anyone know what is the default debug_level for sssd daemon in >ipa? We've found out that some tests (mainly basic-trust) generate >huge volumes of sssd logs which we have to store. A quick glance into >the logs show that these log every tiny bit of really low level >information that we probably never gonna need. We'd like to tweak the >tests to configure sssd for less logging, but I was unable to find >info on default debug_level. The sssd configuration file does not >explicitly specify it. man page sssd.conf: Options usable in all sections debug_level (integer) .... Currently supported debug levels: 0, 0x0010: Fatal failures. Anything that would prevent SSSD from starting up or causes it to cease running. .... Default: 0 -- / Alexander Bokovoy From gkaihoro at redhat.com Mon Aug 15 08:55:08 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Mon, 15 Aug 2016 04:55:08 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts In-Reply-To: References: <256010841.13930537.1470754537126.JavaMail.zimbra@redhat.com> Message-ID: <2017998780.43897958.1471251308082.JavaMail.zimbra@redhat.com> Hello, Petr! Yes, this is exactly what I meant. Martin Basti educated me with that. Best regards, Ganna Kaihorodova Associate Software Quality Engineer ----- Original Message ----- From: "Petr Spacek" To: freeipa-devel at redhat.com Sent: Friday, August 12, 2016 6:58:54 PM Subject: Re: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts On 9.8.2016 16:55, Ganna Kaihorodova wrote: > Hello! > > Domain level 0 doesn't allow to create replica file on CA master, testcase was skipped with Domain level 0 You mean on CA-less master, right? Petr^2 Spacek > https://fedorahosted.org/freeipa/ticket/6134 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From ldoudova at redhat.com Mon Aug 15 09:35:46 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 15 Aug 2016 11:35:46 +0200 Subject: [Freeipa-devel] [PATCH 0031, 0032][Tests] Fixes for failing test_ipalib/test_messages tests Message-ID: <08beb447-3dc1-3fd5-3191-37a10320ba58@redhat.com> Hi, attached are patches that are fixing 3 failing tests in test_ipalib/test_messages.py. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0031-Fix-malformed-or-missing-docstrings-in-ipalib-messag.patch Type: text/x-patch Size: 2330 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0032-Tests-Add-data-attribute-to-messages.patch Type: text/x-patch Size: 1966 bytes Desc: not available URL: From gkaihoro at redhat.com Mon Aug 15 10:46:18 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Mon, 15 Aug 2016 06:46:18 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts In-Reply-To: <2017998780.43897958.1471251308082.JavaMail.zimbra@redhat.com> References: <256010841.13930537.1470754537126.JavaMail.zimbra@redhat.com> <2017998780.43897958.1471251308082.JavaMail.zimbra@redhat.com> Message-ID: <63652041.43937962.1471257978245.JavaMail.zimbra@redhat.com> Hello! I fixed typo in commit message. Best regards, Ganna Kaihorodova Associate Software Quality Engineer ----- Original Message ----- From: "Ganna Kaihorodova" To: "Petr Spacek" Cc: freeipa-devel at redhat.com Sent: Monday, August 15, 2016 10:55:08 AM Subject: Re: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts Hello, Petr! Yes, this is exactly what I meant. Martin Basti educated me with that. Best regards, Ganna Kaihorodova Associate Software Quality Engineer ----- Original Message ----- From: "Petr Spacek" To: freeipa-devel at redhat.com Sent: Friday, August 12, 2016 6:58:54 PM Subject: Re: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts On 9.8.2016 16:55, Ganna Kaihorodova wrote: > Hello! > > Domain level 0 doesn't allow to create replica file on CA master, testcase was skipped with Domain level 0 You mean on CA-less master, right? Petr^2 Spacek > https://fedorahosted.org/freeipa/ticket/6134 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-gkaihoro-0003-2-Fix-for-integration-tests-replication-layouts.patch Type: text/x-patch Size: 2195 bytes Desc: not available URL: From jcholast at redhat.com Mon Aug 15 12:08:54 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 15 Aug 2016 14:08:54 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name In-Reply-To: <4f7384ee-e648-2adb-3c86-26e297ede481@redhat.com> References: <20160715050448.GE10771@dhcp-40-8.bne.redhat.com> <20160715050539.GF10771@dhcp-40-8.bne.redhat.com> <83eb61a6-4e1f-d33a-1bbb-dacf8de522af@redhat.com> <20160719095445.GU10771@dhcp-40-8.bne.redhat.com> <4f7384ee-e648-2adb-3c86-26e297ede481@redhat.com> Message-ID: <63eec8fe-b64d-00db-f516-ccff6e8220a5@redhat.com> On 19.7.2016 12:05, Jan Cholasta wrote: > On 19.7.2016 11:54, Fraser Tweedale wrote: >> On Tue, Jul 19, 2016 at 09:36:17AM +0200, Jan Cholasta wrote: >>> Hi, >>> >>> On 15.7.2016 07:05, Fraser Tweedale wrote: >>>> On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: >>>>> The attached patch is a work in progress for >>>>> https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). >>>>> >>>>> I am sharing now to make the approach clear and solicit feedback. >>>>> >>>>> It has been tested for server install, replica install (with and >>>>> without CA) and CA-replica install (all hosts running master+patch). >>>>> >>>>> Migration from earlier versions and server/replica/CA install on a >>>>> CA-less deployment are not yet tested; these will be tested over >>>>> coming days and patch will be tweaked as necessary. >>>>> >>>>> Commit message has a fair bit to say so I won't repeat here but let >>>>> me know your questions and comments. >>>>> >>>>> Thanks, >>>>> Fraser >>>>> >>>> It does help to attach the patch, of course ^_^ >>> >>> IMO explicit is better than implicit, so instead of introducing >>> additional >>> magic around --subject, I would rather add a new separate option for >>> specifying the CA subject name (I think --ca-subject, for consistency >>> with >>> --ca-signing-algorithm). >>> >> The current situation - the --subject argument which specifies the >> not the subject but the subject base, is confusing enough (to say >> nothing of the limitations that give rise to the RFE). >> >> Retaining --subject for specifying the subject base and adding >> --ca-subject for specifying the *actual* subject DN gets us over the >> line in terms of the RFE, but does not make the installer less >> confusing. This is why I made --subject accept the full subject DN, >> with provisions to retain existing behaviour. >> >> IMO if we want to have separate arguments for subject DN and subject >> base (I am not against it), let's bite the bullet and name arguments >> accordingly. --subject should be used to specify full Subject DN, >> --subject-base (or similar) for specifying subject base. > > IMHO --ca-subject is better than --subject, because it is more explicit > whose subject name that is (the CA's). I agree that --subject should be > deprecated and replaced with --subject-base. > >> >> (I intentionally defer discussion of specific behaviour if one, none >> or both are specified; let's resolve the question or renaming / >> changing meaning of arguments first). >> >> >>> By specifying the option you would override the default "CN=Certificate >>> Authority,$SUBJECT_BASE" subject name. If --external-ca was not used, >>> additional validation would be done to make sure the subject name meets >>> Dogtag's expectations. Actually, it might make sense to always do the >>> additional validation, to be able to print a warning that if a >>> Dogtag-incompatible subject name is used, it won't be possible to >>> change the >>> CA cert chaining from externally signed to self-signed later. >>> >>> Honza Bump, any update on this? -- Jan Cholasta From mbabinsk at redhat.com Mon Aug 15 12:13:36 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 15 Aug 2016 14:13:36 +0200 Subject: [Freeipa-devel] [PATCH 0063] Raise error on topology disconnect/last-role-host removal during server uninstall In-Reply-To: <4b103ebb-cd29-1705-456f-fd7965abc2a6@redhat.com> References: <4b103ebb-cd29-1705-456f-fd7965abc2a6@redhat.com> Message-ID: On 08/12/2016 12:08 PM, Stanislav Laznicka wrote: > Hello, > > topology disconnect/last-role-host removal errors would just be logged > during server uninstall even if ignore options are not present. The host > would still appear in the topology even after "successful" uninstall. > > https://fedorahosted.org/freeipa/ticket/6168 > > > The patch seems to be ok, however shouldn't we use sys.exit() when handling ServerRemovalError? Yes raising SystemExit from within a function is a horrible practice, but it is already done on several other places instead of letting the exception bubble up to the main handler. CC'ing Jan for his thoughts on this since I may be wrong. -- Martin^3 Babinsky From mbabinsk at redhat.com Mon Aug 15 12:20:40 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 15 Aug 2016 14:20:40 +0200 Subject: [Freeipa-devel] [PATCH 0063] Raise error on topology disconnect/last-role-host removal during server uninstall In-Reply-To: References: <4b103ebb-cd29-1705-456f-fd7965abc2a6@redhat.com> Message-ID: <448657e9-d35d-ffa9-8582-761c3d733aa9@redhat.com> On 08/15/2016 02:13 PM, Martin Babinsky wrote: > On 08/12/2016 12:08 PM, Stanislav Laznicka wrote: >> Hello, >> >> topology disconnect/last-role-host removal errors would just be logged >> during server uninstall even if ignore options are not present. The host >> would still appear in the topology even after "successful" uninstall. >> >> https://fedorahosted.org/freeipa/ticket/6168 >> >> >> > > The patch seems to be ok, however shouldn't we use sys.exit() when > handling ServerRemovalError? Yes raising SystemExit from within a > function is a horrible practice, but it is already done on several other > places instead of letting the exception bubble up to the main handler. > > CC'ing Jan for his thoughts on this since I may be wrong. > Hmm, you will definitely need sys.exit() here since otherwise ipa-server-install reports 0 exit code even if there was an exception thrown: """ [root at master1 ~]# ipa-server-install --uninstall -U ipa : ERROR Server removal aborted: Deleting this server will leave your installation without a DNS.. [root at master1 ~]# echo $? 0 """ -- Martin^3 Babinsky From ldoudova at redhat.com Mon Aug 15 12:27:25 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 15 Aug 2016 14:27:25 +0200 Subject: [Freeipa-devel] [PATCH 0033][Tests] Fix test_ipalib/test_output failing due to change of Output class behaviour Message-ID: <6e6d97ff-ab33-f5c6-9a54-f31aa3f44571@redhat.com> Hi, attaching patch for https://fedorahosted.org/freeipa/ticket/6189 Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0033-Tests-test_ipalib-test_output-fails-due-to-change-of.patch Type: text/x-patch Size: 1537 bytes Desc: not available URL: From mkubik at redhat.com Mon Aug 15 12:35:22 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 15 Aug 2016 14:35:22 +0200 Subject: [Freeipa-devel] [patch 0052] ipatests: Fix wrong fixture in kerberos principal alias test Message-ID: <4fbd1a0b-31c9-396d-0af2-1f98a2638109@redhat.com> Fixes issue in ticket https://fedorahosted.org/freeipa/ticket/6197 -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0052-ipatests-Fix-wrong-fixture-in-kerberos-principal-ali.patch Type: text/x-patch Size: 1022 bytes Desc: not available URL: From pspacek at redhat.com Mon Aug 15 12:52:46 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Aug 2016 14:52:46 +0200 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> Message-ID: <6e5f6d1b-5629-f3b1-fe5d-24593795bf65@redhat.com> On 2.8.2016 05:57, Fraser Tweedale wrote: >> > Hah! This is what I get for thinking I know what the output has to look >> > like, and not testing all the way through to requesting the cert. I'll >> > change the profile to generate a subject with CN= instead of UID=. Updated >> > patch is attached. Unfortunately these rules are only updated at >> > ipa-server-install time, so if you'd like to fix it without reinstalling: >> > > (Tangential commentary...) Yeah, currently cert-request demands the > CN. There is a design to relax the requirement to handle empty > subject names (look at SAN only). IMO it would make sense to accept > other "obvious" mappings in Subject DN like accepting UID instead of > CN for user subjects, but that would be a separate RFE. Noone has > actually asked for it yet :) Side-note: I thought that subject format is enforced by certificate profile on server. Am I wrong? -- Petr^2 Spacek From ftweedal at redhat.com Mon Aug 15 12:54:25 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 15 Aug 2016 22:54:25 +1000 Subject: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name In-Reply-To: <63eec8fe-b64d-00db-f516-ccff6e8220a5@redhat.com> References: <20160715050448.GE10771@dhcp-40-8.bne.redhat.com> <20160715050539.GF10771@dhcp-40-8.bne.redhat.com> <83eb61a6-4e1f-d33a-1bbb-dacf8de522af@redhat.com> <20160719095445.GU10771@dhcp-40-8.bne.redhat.com> <4f7384ee-e648-2adb-3c86-26e297ede481@redhat.com> <63eec8fe-b64d-00db-f516-ccff6e8220a5@redhat.com> Message-ID: <20160815125425.GM23927@dhcp-40-8.bne.redhat.com> On Mon, Aug 15, 2016 at 02:08:54PM +0200, Jan Cholasta wrote: > On 19.7.2016 12:05, Jan Cholasta wrote: > > On 19.7.2016 11:54, Fraser Tweedale wrote: > > > On Tue, Jul 19, 2016 at 09:36:17AM +0200, Jan Cholasta wrote: > > > > Hi, > > > > > > > > On 15.7.2016 07:05, Fraser Tweedale wrote: > > > > > On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: > > > > > > The attached patch is a work in progress for > > > > > > https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). > > > > > > > > > > > > I am sharing now to make the approach clear and solicit feedback. > > > > > > > > > > > > It has been tested for server install, replica install (with and > > > > > > without CA) and CA-replica install (all hosts running master+patch). > > > > > > > > > > > > Migration from earlier versions and server/replica/CA install on a > > > > > > CA-less deployment are not yet tested; these will be tested over > > > > > > coming days and patch will be tweaked as necessary. > > > > > > > > > > > > Commit message has a fair bit to say so I won't repeat here but let > > > > > > me know your questions and comments. > > > > > > > > > > > > Thanks, > > > > > > Fraser > > > > > > > > > > > It does help to attach the patch, of course ^_^ > > > > > > > > IMO explicit is better than implicit, so instead of introducing > > > > additional > > > > magic around --subject, I would rather add a new separate option for > > > > specifying the CA subject name (I think --ca-subject, for consistency > > > > with > > > > --ca-signing-algorithm). > > > > > > > The current situation - the --subject argument which specifies the > > > not the subject but the subject base, is confusing enough (to say > > > nothing of the limitations that give rise to the RFE). > > > > > > Retaining --subject for specifying the subject base and adding > > > --ca-subject for specifying the *actual* subject DN gets us over the > > > line in terms of the RFE, but does not make the installer less > > > confusing. This is why I made --subject accept the full subject DN, > > > with provisions to retain existing behaviour. > > > > > > IMO if we want to have separate arguments for subject DN and subject > > > base (I am not against it), let's bite the bullet and name arguments > > > accordingly. --subject should be used to specify full Subject DN, > > > --subject-base (or similar) for specifying subject base. > > > > IMHO --ca-subject is better than --subject, because it is more explicit > > whose subject name that is (the CA's). I agree that --subject should be > > deprecated and replaced with --subject-base. > > > > > > > > (I intentionally defer discussion of specific behaviour if one, none > > > or both are specified; let's resolve the question or renaming / > > > changing meaning of arguments first). > > > > > > > > > > By specifying the option you would override the default "CN=Certificate > > > > Authority,$SUBJECT_BASE" subject name. If --external-ca was not used, > > > > additional validation would be done to make sure the subject name meets > > > > Dogtag's expectations. Actually, it might make sense to always do the > > > > additional validation, to be able to print a warning that if a > > > > Dogtag-incompatible subject name is used, it won't be possible to > > > > change the > > > > CA cert chaining from externally signed to self-signed later. > > > > > > > > Honza > > Bump, any update on this? > I have an updated patch that fixes some issues Sebastian encountered in testing, but I've not yet tackled the main change requested by Honza (in brief: adding --ca-subject for specifying that, adding --subject-base for specifying that, and deprecating --subject; Sebastian, see discussion above and feel free to give your thoughts). I expect I'll get back onto this work within the next few days. Thanks, Fraser From ftweedal at redhat.com Mon Aug 15 13:07:35 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 15 Aug 2016 23:07:35 +1000 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: <7d3265a6-defe-d45c-9491-26d8ec4b3927@redhat.com> References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> <7d7647ba-d9b0-6be8-18a6-5dbcf178c68c@redhat.com> <7d3265a6-defe-d45c-9491-26d8ec4b3927@redhat.com> Message-ID: <20160815130734.GN23927@dhcp-40-8.bne.redhat.com> On Mon, Aug 15, 2016 at 07:48:22AM +0200, Jan Cholasta wrote: > On 12.8.2016 18:57, Petr Spacek wrote: > > On 12.8.2016 11:33, Jan Cholasta wrote: > > > On 4.8.2016 18:18, Petr Vobornik wrote: > > > > On 07/22/2016 07:13 AM, Fraser Tweedale wrote: > > > > > On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote: > > > > > > Hi, > > > > > > > > > > > > On 14.7.2016 13:44, Fraser Tweedale wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > The attached patch includes SANs in cert-show output. If you have > > > > > > > certs with esoteric altnames (especially any that are more than just > > > > > > > ASN.1 string types), please test with those certs. > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6022 > > > > > > > > > > > > I think it would be better to have a separate attribute for each supported > > > > > > SAN type rather than cramming everything into subject_alt_name. That way if > > > > > > you care only about a single specific type you won't have to go through all > > > > > > the values and parse them. Also it would allow you to use param types > > > > > > appropriate to the SAN types (DNSNameParam for DNS names, Principal for > > > > > > principal names, etc.) > > > > > > > > > > > > Nitpick: please don't mix moving existing stuff and adding new stuff in a > > > > > > single patch. > > > > > > > > > > > Updated patches attached. > > > > > > > > > > Patches 0092..0094 are refactors and bugfixes. > > > > > Patch 0090-2 is the main feature (depends on 0092..0094). > > > > > > > > > > Thanks, > > > > > Fraser > > > > > > > > > > > > > bump for review > > > > > > Patch 0092: ACK > > > > > > Patch 0093: ACK > > > > > > Patch 0094: ACK > > > > > > Patch 0090: > > > > > > 1) Generic otherNames (san_other) do not work correctly. The OID is not > > > included in the value and names with complex type other than KerberosPrincipal > > > are not parsed correctly. The value should include the OID and DER blob of the > > > name. > > > > > > 2) With --all, san_other should be included in the result for all otherNames, > > > even the known ones, to provide (limited) forward compatibility. > > > > > > 3) Do we have to support *all* the name types? I mean we could, for the sake > > > of completeness, but it might be easier to just keep the few ones we actually > > > care about (email, DNS name, principal name, UPN and directory name in your > > > patch 0095). > > > > As far as I remember this reasoning usually comes back to bite us into butt. > > > > - "Implement only this subset, nobody else needs the other the of ... > > (whatever, e.g. DNS record type)." > > - "Yes my lord." > > > > Two months later: > > > > - "We need to support for XYZ. It was (already) late yesterday!" > > > > :-) > > Care to give a concrete example of when this actually happened? Because IIRC > this happened once or twice, not "usually". > > Anyway, I'm fine with whatever, my point was that additional effort needs to > be put in to support "everything" and even then, we wouldn't actually > support everything (two months later: "we need to support extension XYZ!"). > Sure, but in this case it was minimal additional effort to support even the esoteric name types - it is only for display after all; if an uncommon altname is (somehow) there we can display it. > (FWIW, I think it would be more useful to add support for Basic constraints > rather than X.400 SANs.) > I can only agree, and say: another RFE for another day :) > > > > Petr^2 Spacek > > > > > > > > 4) > > > > > > + obj.setdefault(attr_name, []).append(unicode(name)) > > > > > > The value should not (always) be unicode, but of the type declared by the > > > param (unicode or ipapython.kerberos.Principal or ipapython.dnsutil.DNSName). > > > > > -- > Jan Cholasta > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From ftweedal at redhat.com Mon Aug 15 13:16:25 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 15 Aug 2016 23:16:25 +1000 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <6e5f6d1b-5629-f3b1-fe5d-24593795bf65@redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> <6e5f6d1b-5629-f3b1-fe5d-24593795bf65@redhat.com> Message-ID: <20160815131625.GO23927@dhcp-40-8.bne.redhat.com> On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote: > On 2.8.2016 05:57, Fraser Tweedale wrote: > >> > Hah! This is what I get for thinking I know what the output has to look > >> > like, and not testing all the way through to requesting the cert. I'll > >> > change the profile to generate a subject with CN= instead of UID=. Updated > >> > patch is attached. Unfortunately these rules are only updated at > >> > ipa-server-install time, so if you'd like to fix it without reinstalling: > >> > > > (Tangential commentary...) Yeah, currently cert-request demands the > > CN. There is a design to relax the requirement to handle empty > > subject names (look at SAN only). IMO it would make sense to accept > > other "obvious" mappings in Subject DN like accepting UID instead of > > CN for user subjects, but that would be a separate RFE. Noone has > > actually asked for it yet :) > > Side-note: > I thought that subject format is enforced by certificate profile on server. > Am I wrong? > You are right - what I suggested above would (today) require a custom profile. From pspacek at redhat.com Mon Aug 15 13:30:11 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Aug 2016 15:30:11 +0200 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: <20160815130734.GN23927@dhcp-40-8.bne.redhat.com> References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> <7d7647ba-d9b0-6be8-18a6-5dbcf178c68c@redhat.com> <7d3265a6-defe-d45c-9491-26d8ec4b3927@redhat.com> <20160815130734.GN23927@dhcp-40-8.bne.redhat.com> Message-ID: On 15.8.2016 15:07, Fraser Tweedale wrote: > On Mon, Aug 15, 2016 at 07:48:22AM +0200, Jan Cholasta wrote: >> On 12.8.2016 18:57, Petr Spacek wrote: >>> On 12.8.2016 11:33, Jan Cholasta wrote: >>>> On 4.8.2016 18:18, Petr Vobornik wrote: >>>>> On 07/22/2016 07:13 AM, Fraser Tweedale wrote: >>>>>> On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 14.7.2016 13:44, Fraser Tweedale wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> The attached patch includes SANs in cert-show output. If you have >>>>>>>> certs with esoteric altnames (especially any that are more than just >>>>>>>> ASN.1 string types), please test with those certs. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/6022 >>>>>>> >>>>>>> I think it would be better to have a separate attribute for each supported >>>>>>> SAN type rather than cramming everything into subject_alt_name. That way if >>>>>>> you care only about a single specific type you won't have to go through all >>>>>>> the values and parse them. Also it would allow you to use param types >>>>>>> appropriate to the SAN types (DNSNameParam for DNS names, Principal for >>>>>>> principal names, etc.) >>>>>>> >>>>>>> Nitpick: please don't mix moving existing stuff and adding new stuff in a >>>>>>> single patch. >>>>>>> >>>>>> Updated patches attached. >>>>>> >>>>>> Patches 0092..0094 are refactors and bugfixes. >>>>>> Patch 0090-2 is the main feature (depends on 0092..0094). >>>>>> >>>>>> Thanks, >>>>>> Fraser >>>>>> >>>>> >>>>> bump for review >>>> >>>> Patch 0092: ACK >>>> >>>> Patch 0093: ACK >>>> >>>> Patch 0094: ACK >>>> >>>> Patch 0090: >>>> >>>> 1) Generic otherNames (san_other) do not work correctly. The OID is not >>>> included in the value and names with complex type other than KerberosPrincipal >>>> are not parsed correctly. The value should include the OID and DER blob of the >>>> name. >>>> >>>> 2) With --all, san_other should be included in the result for all otherNames, >>>> even the known ones, to provide (limited) forward compatibility. >>>> >>>> 3) Do we have to support *all* the name types? I mean we could, for the sake >>>> of completeness, but it might be easier to just keep the few ones we actually >>>> care about (email, DNS name, principal name, UPN and directory name in your >>>> patch 0095). >>> >>> As far as I remember this reasoning usually comes back to bite us into butt. >>> >>> - "Implement only this subset, nobody else needs the other the of ... >>> (whatever, e.g. DNS record type)." >>> - "Yes my lord." >>> >>> Two months later: >>> >>> - "We need to support for XYZ. It was (already) late yesterday!" >>> >>> :-) >> >> Care to give a concrete example of when this actually happened? Because IIRC >> this happened once or twice, not "usually". I do not have list at hand, sorry. It is just my feeling. >> Anyway, I'm fine with whatever, my point was that additional effort needs to >> be put in to support "everything" and even then, we wouldn't actually >> support everything (two months later: "we need to support extension XYZ!"). >> > Sure, but in this case it was minimal additional effort to support > even the esoteric name types - it is only for display after all; if > an uncommon altname is (somehow) there we can display it. That is the main point. The cost is minimal so why not to do it? Petr^2 Spacek >> (FWIW, I think it would be more useful to add support for Basic constraints >> rather than X.400 SANs.) >> > I can only agree, and say: another RFE for another day :) > >>> >>> Petr^2 Spacek >>> >>>> >>>> 4) >>>> >>>> + obj.setdefault(attr_name, []).append(unicode(name)) >>>> >>>> The value should not (always) be unicode, but of the type declared by the >>>> param (unicode or ipapython.kerberos.Principal or ipapython.dnsutil.DNSName). From pspacek at redhat.com Mon Aug 15 13:31:20 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Aug 2016 15:31:20 +0200 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <20160815131625.GO23927@dhcp-40-8.bne.redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> <6e5f6d1b-5629-f3b1-fe5d-24593795bf65@redhat.com> <20160815131625.GO23927@dhcp-40-8.bne.redhat.com> Message-ID: <35967055-8dc6-58e2-3c15-2b1187da3435@redhat.com> On 15.8.2016 15:16, Fraser Tweedale wrote: > On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote: >> On 2.8.2016 05:57, Fraser Tweedale wrote: >>>>> Hah! This is what I get for thinking I know what the output has to look >>>>> like, and not testing all the way through to requesting the cert. I'll >>>>> change the profile to generate a subject with CN= instead of UID=. Updated >>>>> patch is attached. Unfortunately these rules are only updated at >>>>> ipa-server-install time, so if you'd like to fix it without reinstalling: >>>>> >>> (Tangential commentary...) Yeah, currently cert-request demands the >>> CN. There is a design to relax the requirement to handle empty >>> subject names (look at SAN only). IMO it would make sense to accept >>> other "obvious" mappings in Subject DN like accepting UID instead of >>> CN for user subjects, but that would be a separate RFE. Noone has >>> actually asked for it yet :) >> >> Side-note: >> I thought that subject format is enforced by certificate profile on server. >> Am I wrong? >> > You are right - what I suggested above would (today) require a > custom profile. Sooo... can we just relax existing profiles not to require CN= but accept SAN-only CSRs? :-) -- Petr^2 Spacek From ftweedal at redhat.com Mon Aug 15 13:54:33 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 15 Aug 2016 23:54:33 +1000 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <35967055-8dc6-58e2-3c15-2b1187da3435@redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> <6e5f6d1b-5629-f3b1-fe5d-24593795bf65@redhat.com> <20160815131625.GO23927@dhcp-40-8.bne.redhat.com> <35967055-8dc6-58e2-3c15-2b1187da3435@redhat.com> Message-ID: <20160815135432.GP23927@dhcp-40-8.bne.redhat.com> On Mon, Aug 15, 2016 at 03:31:20PM +0200, Petr Spacek wrote: > On 15.8.2016 15:16, Fraser Tweedale wrote: > > On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote: > >> On 2.8.2016 05:57, Fraser Tweedale wrote: > >>>>> Hah! This is what I get for thinking I know what the output has to look > >>>>> like, and not testing all the way through to requesting the cert. I'll > >>>>> change the profile to generate a subject with CN= instead of UID=. Updated > >>>>> patch is attached. Unfortunately these rules are only updated at > >>>>> ipa-server-install time, so if you'd like to fix it without reinstalling: > >>>>> > >>> (Tangential commentary...) Yeah, currently cert-request demands the > >>> CN. There is a design to relax the requirement to handle empty > >>> subject names (look at SAN only). IMO it would make sense to accept > >>> other "obvious" mappings in Subject DN like accepting UID instead of > >>> CN for user subjects, but that would be a separate RFE. Noone has > >>> actually asked for it yet :) > >> > >> Side-note: > >> I thought that subject format is enforced by certificate profile on server. > >> Am I wrong? > >> > > You are right - what I suggested above would (today) require a > > custom profile. > > Sooo... > can we just relax existing profiles not to require CN= but accept SAN-only CSRs? > > :-) > That is absolutely going to happen as part of http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance :) From pspacek at redhat.com Mon Aug 15 13:58:40 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Aug 2016 15:58:40 +0200 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <20160815135432.GP23927@dhcp-40-8.bne.redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> <6e5f6d1b-5629-f3b1-fe5d-24593795bf65@redhat.com> <20160815131625.GO23927@dhcp-40-8.bne.redhat.com> <35967055-8dc6-58e2-3c15-2b1187da3435@redhat.com> <20160815135432.GP23927@dhcp-40-8.bne.redhat.com> Message-ID: <0b57369b-57d6-4567-1a4d-ae3c63ba1bbf@redhat.com> On 15.8.2016 15:54, Fraser Tweedale wrote: > On Mon, Aug 15, 2016 at 03:31:20PM +0200, Petr Spacek wrote: >> On 15.8.2016 15:16, Fraser Tweedale wrote: >>> On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote: >>>> On 2.8.2016 05:57, Fraser Tweedale wrote: >>>>>>> Hah! This is what I get for thinking I know what the output has to look >>>>>>> like, and not testing all the way through to requesting the cert. I'll >>>>>>> change the profile to generate a subject with CN= instead of UID=. Updated >>>>>>> patch is attached. Unfortunately these rules are only updated at >>>>>>> ipa-server-install time, so if you'd like to fix it without reinstalling: >>>>>>> >>>>> (Tangential commentary...) Yeah, currently cert-request demands the >>>>> CN. There is a design to relax the requirement to handle empty >>>>> subject names (look at SAN only). IMO it would make sense to accept >>>>> other "obvious" mappings in Subject DN like accepting UID instead of >>>>> CN for user subjects, but that would be a separate RFE. Noone has >>>>> actually asked for it yet :) >>>> >>>> Side-note: >>>> I thought that subject format is enforced by certificate profile on server. >>>> Am I wrong? >>>> >>> You are right - what I suggested above would (today) require a >>> custom profile. >> >> Sooo... >> can we just relax existing profiles not to require CN= but accept SAN-only CSRs? >> >> :-) >> > That is absolutely going to happen as part of > http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance :) Good! Is it still targeting 4.4.x? -- Petr^2 Spacek From abokovoy at redhat.com Mon Aug 15 16:06:07 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Aug 2016 19:06:07 +0300 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes Message-ID: <20160815160607.wky5extyyrmydgb4@redhat.com> Hi! Attached are trust-related patches. 0207 is a pre-requisite. I did send it before, it is re-formatting of the ipaserver/dcerpc.py to be close to PEP8 requirements. 0218 is an automated trust topology conflict resolver for DNS namespace conflicts. Read the commit message for details, and also comments in the code. With this patch FreeIPA becomes more smart than Windows Server which doesn't have automated trust topology conflict resolution. ;) 0219 fixes issue of topology details leaking through external trust. The problem is only in presentation as we store more data than needed -- it is impossible to cross external trust boundary anyway as it is handled by AD DC side, but one important consequence is that we need to store UPN suffixes before we start storing information about child domains. Again, read the commit message. These patches also are on top of my previously sent patches 0215-0216. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Aug 15 16:06:48 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Aug 2016 19:06:48 +0300 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: <20160815160607.wky5extyyrmydgb4@redhat.com> References: <20160815160607.wky5extyyrmydgb4@redhat.com> Message-ID: <20160815160648.o2afooo4w5vycmt6@redhat.com> On Mon, 15 Aug 2016, Alexander Bokovoy wrote: >Hi! > >Attached are trust-related patches. > >0207 is a pre-requisite. I did send it before, it is re-formatting of >the ipaserver/dcerpc.py to be close to PEP8 requirements. > >0218 is an automated trust topology conflict resolver for DNS namespace >conflicts. Read the commit message for details, and also comments in the >code. With this patch FreeIPA becomes more smart than Windows Server >which doesn't have automated trust topology conflict resolution. ;) > >0219 fixes issue of topology details leaking through external trust. The >problem is only in presentation as we store more data than needed -- it >is impossible to cross external trust boundary anyway as it is handled >by AD DC side, but one important consequence is that we need to store >UPN suffixes before we start storing information about child domains. >Again, read the commit message. > >These patches also are on top of my previously sent patches 0215-0216. Patches attached. -- / Alexander Bokovoy -------------- next part -------------- From 356f5b81af065ee808ab953c7103ae536cd0136f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 7 Jun 2016 22:41:10 +0300 Subject: [PATCH 07/10] ipaserver/dcerpc: reformat to make the code closer to pep8 Because Samba Python bindings provide long-named methods and constants, sometimes it is impossible to fit into 80 columns without causing damage to readability of the code. This patchset attempts to reduce pep8 complaints to a minimum. --- ipaserver/dcerpc.py | 473 +++++++++++++++++++++++++++++++++------------------- 1 file changed, 298 insertions(+), 175 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 21ac89d..19be6bf 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -44,10 +44,12 @@ import samba import random from cryptography.hazmat.primitives.ciphers import Cipher, algorithms from cryptography.hazmat.backends import default_backend +# pylint: disable=F0401 try: - from ldap.controls import RequestControl as LDAPControl #pylint: disable=F0401 + from ldap.controls import RequestControl as LDAPControl except ImportError: - from ldap.controls import LDAPControl as LDAPControl #pylint: disable=F0401 + from ldap.controls import LDAPControl as LDAPControl +# pylint: enable=F0401 import ldap as _ldap from ipapython.ipaldap import IPAdmin from ipaserver.session import krbccache_dir, krbccache_prefix @@ -74,7 +76,7 @@ and Samba4 python bindings. # Both constants can be used as masks against trust direction # because bi-directional has two lower bits set. -TRUST_ONEWAY = 1 +TRUST_ONEWAY = 1 TRUST_BIDIRECTIONAL = 3 # Trust join behavior @@ -91,31 +93,44 @@ def is_sid_valid(sid): return True -access_denied_error = errors.ACIError(info=_('CIFS server denied your credentials')) +access_denied_error = errors.ACIError( + info=_('CIFS server denied your credentials')) dcerpc_error_codes = { -1073741823: - errors.RemoteRetrieveError(reason=_('communication with CIFS server was unsuccessful')), + errors.RemoteRetrieveError( + reason=_('communication with CIFS server was unsuccessful')), -1073741790: access_denied_error, -1073741715: access_denied_error, -1073741614: access_denied_error, -1073741603: - errors.ValidationError(name=_('AD domain controller'), error=_('unsupported functional level')), - -1073741811: # NT_STATUS_INVALID_PARAMETER + errors.ValidationError( + name=_('AD domain controller'), + error=_('unsupported functional level')), + -1073741811: # NT_STATUS_INVALID_PARAMETER errors.RemoteRetrieveError( - reason=_('AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example')), - -1073741776: # NT_STATUS_INVALID_PARAMETER_MIX, we simply will skip the binding + reason=_('AD domain controller complains about communication ' + 'sequence. It may mean unsynchronized time on both ' + 'sides, for example')), + -1073741776: # NT_STATUS_INVALID_PARAMETER_MIX, + # we simply will skip the binding access_denied_error, - -1073741772: # NT_STATUS_OBJECT_NAME_NOT_FOUND - errors.RemoteRetrieveError(reason=_('CIFS server configuration does not allow access to \\\\pipe\\lsarpc')), + -1073741772: # NT_STATUS_OBJECT_NAME_NOT_FOUND + errors.RemoteRetrieveError( + reason=_('CIFS server configuration does not allow ' + 'access to \\\\pipe\\lsarpc')), } dcerpc_error_messages = { "NT_STATUS_OBJECT_NAME_NOT_FOUND": - errors.NotFound(reason=_('Cannot find specified domain or server name')), + errors.NotFound( + reason=_('Cannot find specified domain or server name')), "WERR_NO_LOGON_SERVERS": - errors.RemoteRetrieveError(reason=_('AD DC was unable to reach any IPA domain controller. Most likely it is a DNS or firewall issue')), + errors.RemoteRetrieveError( + reason=_('AD DC was unable to reach any IPA domain controller. ' + 'Most likely it is a DNS or firewall issue')), "NT_STATUS_INVALID_PARAMETER_MIX": - errors.RequirementError(name=_('At least the domain or IP address should be specified')), + errors.RequirementError( + name=_('At least the domain or IP address should be specified')), } pysss_type_key_translation_dict = { @@ -126,7 +141,7 @@ pysss_type_key_translation_dict = { } -def assess_dcerpc_exception(num=None,message=None): +def assess_dcerpc_exception(num=None, message=None): """ Takes error returned by Samba bindings and converts it into an IPA error class. @@ -135,8 +150,9 @@ def assess_dcerpc_exception(num=None,message=None): return dcerpc_error_codes[num] if message and message in dcerpc_error_messages: return dcerpc_error_messages[message] - reason = _('''CIFS server communication error: code "%(num)s", - message "%(message)s" (both may be "None")''') % dict(num=num, message=message) + reason = _('CIFS server communication error: code "%(num)s", ' + 'message "%(message)s" (both may be "None")') % \ + dict(num=num, message=message) return errors.RemoteRetrieveError(reason=reason) @@ -182,9 +198,13 @@ class DomainValidator(object): self._parm = None def is_configured(self): - cn_trust_local = DN(('cn', self.api.env.domain), self.api.env.container_cifsdomains, self.api.env.basedn) + cn_trust_local = DN(('cn', self.api.env.domain), + self.api.env.container_cifsdomains, + self.api.env.basedn) try: - entry_attrs = self.ldap.get_entry(cn_trust_local, [self.ATTR_FLATNAME, self.ATTR_SID]) + entry_attrs = self.ldap.get_entry(cn_trust_local, + [self.ATTR_FLATNAME, + self.ATTR_SID]) self.flatname = entry_attrs[self.ATTR_FLATNAME][0] self.sid = entry_attrs[self.ATTR_SID][0] self.dn = entry_attrs.dn @@ -203,7 +223,8 @@ class DomainValidator(object): try: search_kw = {'objectClass': 'ipaNTTrustedDomain'} - filter = self.ldap.make_filter(search_kw, rules=self.ldap.MATCH_ALL) + filter = self.ldap.make_filter(search_kw, + rules=self.ldap.MATCH_ALL) (entries, truncated) = self.ldap.find_entries( filter=filter, base_dn=cn_trust, @@ -216,22 +237,22 @@ class DomainValidator(object): # domain names as keys and those are generally case-insensitive result = ipautil.CIDict() - for entry in entries: + for e in entries: try: - trust_partner = entry[self.ATTR_TRUST_PARTNER][0] - flatname_normalized = entry[self.ATTR_FLATNAME][0].lower() - trusted_sid = entry[self.ATTR_TRUSTED_SID][0] - except KeyError as e: + t_partner = e.single_value.get(self.ATTR_TRUST_PARTNER) + fname_norm = e.single_value.get(self.ATTR_FLATNAME).lower() + trusted_sid = e.single_value.get(self.ATTR_TRUSTED_SID) + except KeyError as exc: # Some piece of trusted domain info in LDAP is missing # Skip the domain, but leave log entry for investigation api.log.warning("Trusted domain '%s' entry misses an " - "attribute: %s", entry.dn, e) + "attribute: %s", e.dn, exc) continue - result[trust_partner] = (flatname_normalized, - security.dom_sid(trusted_sid)) + result[t_partner] = (fname_norm, + security.dom_sid(trusted_sid)) return result - except errors.NotFound as e: + except errors.NotFound as exc: return [] def set_trusted_domains(self): @@ -244,21 +265,22 @@ class DomainValidator(object): # This means we can't check the correctness of a trusted # domain SIDs raise errors.ValidationError(name='sid', - error=_('no trusted domain is configured')) + error=_('no trusted domain ' + 'is configured')) def get_domain_by_sid(self, sid, exact_match=False): if not self.domain: # our domain is not configured or self.is_configured() never run # reject SIDs as we can't check correctness of them raise errors.ValidationError(name='sid', - error=_('domain is not configured')) + error=_('domain is not configured')) # Parse sid string to see if it is really in a SID format try: test_sid = security.dom_sid(sid) except TypeError: raise errors.ValidationError(name='sid', - error=_('SID is not valid')) + error=_('SID is not valid')) # At this point we have SID_NT_AUTHORITY family SID and really need to # check it against prefixes of domain SIDs we trust to @@ -314,30 +336,34 @@ class DomainValidator(object): return None def get_trusted_domain_objects(self, domain=None, flatname=None, filter="", - attrs=None, scope=_ldap.SCOPE_SUBTREE, basedn=None): + attrs=None, scope=_ldap.SCOPE_SUBTREE, + basedn=None): """ - Search for LDAP objects in a trusted domain specified either by `domain' - or `flatname'. The actual LDAP search is specified by `filter', `attrs', - `scope' and `basedn'. When `basedn' is empty, database root DN is used. + Search for LDAP objects in a trusted domain specified either by + `domain' or `flatname'. The actual LDAP search is specified by + `filter', `attrs', `scope' and `basedn'. When `basedn' is empty, + database root DN is used. """ assert domain is not None or flatname is not None """Returns SID for the trusted domain object (user or group only)""" if not self.domain: # our domain is not configured or self.is_configured() never run raise errors.ValidationError(name=_('Trust setup'), - error=_('Our domain is not configured')) + error=_('Our domain is ' + 'not configured')) if not self._domains: self._domains = self.get_trusted_domains() if len(self._domains) == 0: # Our domain is configured but no trusted domains are configured raise errors.ValidationError(name=_('Trust setup'), - error=_('No trusted domain is not configured')) + error=_('No trusted domain is ' + 'not configured')) entries = None if domain is not None: if domain not in self._domains: raise errors.ValidationError(name=_('trusted domain object'), - error= _('domain is not trusted')) + error=_('domain is not trusted')) # Now we have a name to check against our list of trusted domains entries = self.search_in_dc(domain, filter, attrs, scope, basedn) elif flatname is not None: @@ -347,53 +373,65 @@ class DomainValidator(object): for domain in self._domains: if self._domains[domain][0] == flatname: found_flatname = True - entries = self.search_in_dc(domain, filter, attrs, scope, basedn) + entries = self.search_in_dc(domain, filter, + attrs, scope, basedn) if entries: break if not found_flatname: raise errors.ValidationError(name=_('trusted domain object'), - error= _('no trusted domain matched the specified flat name')) + error=_('no trusted domain ' + 'matched the specified ' + 'flat name')) if not entries: raise errors.NotFound(reason=_('trusted domain object not found')) return entries - def get_trusted_domain_object_sid(self, object_name, fallback_to_ldap=True): + def get_trusted_domain_object_sid(self, object_name, + fallback_to_ldap=True): result = pysss_nss_idmap.getsidbyname(object_name) - if object_name in result and (pysss_nss_idmap.SID_KEY in result[object_name]): + if object_name in result and \ + (pysss_nss_idmap.SID_KEY in result[object_name]): object_sid = result[object_name][pysss_nss_idmap.SID_KEY] return object_sid # If fallback to AD DC LDAP is not allowed, bail out if not fallback_to_ldap: raise errors.ValidationError(name=_('trusted domain object'), - error= _('SSSD was unable to resolve the object to a valid SID')) + error=_('SSSD was unable to resolve ' + 'the object to a valid SID')) # Else, we are going to contact AD DC LDAP components = normalize_name(object_name) if not ('domain' in components or 'flatname' in components): # No domain or realm specified, ambiguous search - raise errors.ValidationError(name=_('trusted domain object'), - error= _('Ambiguous search, user domain was not specified')) + raise errors.ValidationError(name=_('trusted domain object'), + error=_('Ambiguous search, user ' + 'domain was not specified')) attrs = ['objectSid'] - filter = '(&(sAMAccountName=%(name)s)(|(objectClass=user)(objectClass=group)))' \ - % dict(name=components['name']) + filter = '(&(sAMAccountName=%(name)s)' \ + '(|(objectClass=user)(objectClass=group)))' \ + % dict(name=components['name']) scope = _ldap.SCOPE_SUBTREE entries = self.get_trusted_domain_objects(components.get('domain'), - components.get('flatname'), filter, attrs, scope) + components.get('flatname'), + filter, attrs, scope) if len(entries) > 1: # Treat non-unique entries as invalid raise errors.ValidationError(name=_('trusted domain object'), - error= _('Trusted domain did not return a unique object')) + error=_('Trusted domain did not ' + 'return a unique object')) sid = self.__sid_to_str(entries[0]['objectSid'][0]) try: test_sid = security.dom_sid(sid) return unicode(test_sid) except TypeError as e: raise errors.ValidationError(name=_('trusted domain object'), - error= _('Trusted domain did not return a valid SID for the object')) + error=_('Trusted domain did not ' + 'return a valid SID for ' + 'the object')) def get_trusted_domain_object_type(self, name_or_sid): """ @@ -443,7 +481,8 @@ class DomainValidator(object): ) attrs = ['sAMAccountName'] - filter = (r'(&(objectSid=%(sid)s)(|(objectClass=user)(objectClass=group)))' + filter = (r'(&(objectSid=%(sid)s)' + '(|(objectClass=user)(objectClass=group)))' % dict(sid=escaped_sid)) # sid in binary domain = self.get_domain_by_sid(sid) @@ -454,7 +493,8 @@ class DomainValidator(object): if len(entries) > 1: # Treat non-unique entries as invalid raise errors.ValidationError(name=_('trusted domain object'), - error=_('Trusted domain did not return a unique object')) + error=_('Trusted domain did not ' + 'return a unique object')) object_name = ( "%s@%s" % (entries[0].single_value['sAMAccountName'].lower(), @@ -486,27 +526,31 @@ class DomainValidator(object): # Now search a trusted domain for a user with this SID attrs = ['cn'] filter = '(&(objectClass=user)(objectSid=%(sid)s))' \ - % dict(sid=object_name) + % dict(sid=object_name) try: - entries = self.get_trusted_domain_objects(domain=domain, filter=filter, - attrs=attrs, scope=_ldap.SCOPE_SUBTREE) + entries = self.get_trusted_domain_objects(domain=domain, + filter=filter, + attrs=attrs, + scope=_ldap.SCOPE_SUBTREE) except errors.NotFound: raise errors.NotFound(reason=_('trusted domain user not found')) user_dn = entries[0].dn elif domain or flatname: attrs = ['cn'] filter = '(&(sAMAccountName=%(name)s)(objectClass=user))' \ - % dict(name=name) + % dict(name=name) try: entries = self.get_trusted_domain_objects(domain, - flatname, filter, attrs, _ldap.SCOPE_SUBTREE) + flatname, filter, attrs, + _ldap.SCOPE_SUBTREE) except errors.NotFound: raise errors.NotFound(reason=_('trusted domain user not found')) user_dn = entries[0].dn else: # No domain or realm specified, ambiguous search raise errors.ValidationError(name=_('trusted domain object'), - error= _('Ambiguous search, user domain was not specified')) + error=_('Ambiguous search, ' + 'user domain was not specified')) # Get SIDs of user object and it's groups # tokenGroups attribute must be read with a scope BASE for a known user @@ -514,9 +558,11 @@ class DomainValidator(object): attrs = ['objectSID', 'tokenGroups'] filter = "(objectClass=user)" entries = self.get_trusted_domain_objects(domain, - flatname, filter, attrs, _ldap.SCOPE_BASE, user_dn) + flatname, filter, attrs, + _ldap.SCOPE_BASE, user_dn) object_sid = self.__sid_to_str(entries[0]['objectSid'][0]) - group_sids = [self.__sid_to_str(sid) for sid in entries[0]['tokenGroups']] + group_sids = [self.__sid_to_str(sid) + for sid in entries[0]['tokenGroups']] return (object_sid, group_sids) def get_trusted_domain_user_and_groups(self, object_name): @@ -540,11 +586,14 @@ class DomainValidator(object): if is_valid_sid: object_sid = object_name result = pysss_nss_idmap.getnamebysid(object_name) - if object_name in result and (pysss_nss_idmap.NAME_KEY in result[object_name]): - group_list = pysss.getgrouplist(result[object_name][pysss_nss_idmap.NAME_KEY]) + if object_name in result and \ + (pysss_nss_idmap.NAME_KEY in result[object_name]): + group_list = pysss.getgrouplist( + result[object_name][pysss_nss_idmap.NAME_KEY]) else: result = pysss_nss_idmap.getsidbyname(object_name) - if object_name in result and (pysss_nss_idmap.SID_KEY in result[object_name]): + if object_name in result and \ + (pysss_nss_idmap.SID_KEY in result[object_name]): object_sid = result[object_name][pysss_nss_idmap.SID_KEY] group_list = pysss.getgrouplist(object_name) @@ -552,7 +601,10 @@ class DomainValidator(object): return self.__get_trusted_domain_user_and_groups(object_name) group_sids = pysss_nss_idmap.getsidbyname(group_list) - return (object_sid, [el[1][pysss_nss_idmap.SID_KEY] for el in group_sids.items()]) + return ( + object_sid, + [el[1][pysss_nss_idmap.SID_KEY] for el in group_sids.items()] + ) def __sid_to_str(self, sid): """ @@ -561,12 +613,13 @@ class DomainValidator(object): """ sid_rev_num = ord(sid[0]) number_sub_id = ord(sid[1]) - ia = struct.unpack('!Q','\x00\x00'+sid[2:8])[0] + ia = struct.unpack('!Q', '\x00\x00'+sid[2:8])[0] subs = [ - struct.unpack(' 0: self.parm.set('netbios name', hostname) self.creds = creds @@ -810,14 +867,14 @@ class TrustDomainInstance(object): self.validation_attempts = 0 def __gen_lsa_connection(self, binding): - if self.creds is None: - raise errors.RequirementError(name=_('CIFS credentials object')) - try: - result = lsa.lsarpc(binding, self.parm, self.creds) - return result - except RuntimeError as e: - num, message = e.args # pylint: disable=unpacking-non-sequence - raise assess_dcerpc_exception(num=num, message=message) + if self.creds is None: + raise errors.RequirementError(name=_('CIFS credentials object')) + try: + result = lsa.lsarpc(binding, self.parm, self.creds) + return result + except RuntimeError as e: + num, message = e.args # pylint: disable=unpacking-non-sequence + raise assess_dcerpc_exception(num=num, message=message) def init_lsa_pipe(self, remote_host): """ @@ -847,30 +904,35 @@ class TrustDomainInstance(object): # When session key is not available, we just skip this binding session_attempts = session_attempts + 1 - if self._pipe is None and (attempts + session_attempts) == len(bindings): + if self._pipe is None and \ + (attempts + session_attempts) == len(bindings): raise errors.ACIError( - info=_('CIFS server %(host)s denied your credentials') % dict(host=remote_host)) + info=_('CIFS server %(host)s denied your credentials') + % dict(host=remote_host)) if self._pipe is None: raise errors.RemoteRetrieveError( - reason=_('Cannot establish LSA connection to %(host)s. Is CIFS server running?') % dict(host=remote_host)) + reason=_('Cannot establish LSA connection to %(host)s. ' + 'Is CIFS server running?') % dict(host=remote_host)) self.binding = binding self.session_key = self._pipe.session_key def __gen_lsa_bindings(self, remote_host): """ - There are multiple transports to issue LSA calls. However, depending on a - system in use they may be blocked by local operating system policies. + There are multiple transports to issue LSA calls. However, depending on + a system in use they may be blocked by local operating system policies. Generate all we can use. init_lsa_pipe() will try them one by one until there is one working. - We try NCACN_NP before NCACN_IP_TCP and use SMB2 before SMB1 or defaults. + We try NCACN_NP before NCACN_IP_TCP and use SMB2 before SMB1. """ transports = (u'ncacn_np', u'ncacn_ip_tcp') - options = ( u'smb2,print', u'print') - return [u'%s:%s[%s]' % (t, remote_host, o) for t in transports for o in options] + options = (u'smb2,print', u'print') + return [u'%s:%s[%s]' % (t, remote_host, o) + for t in transports for o in options] - def retrieve_anonymously(self, remote_host, discover_srv=False, search_pdc=False): + def retrieve_anonymously(self, remote_host, + discover_srv=False, search_pdc=False): """ When retrieving DC information anonymously, we can't get SID of the domain """ @@ -896,7 +958,8 @@ class TrustDomainInstance(object): self.info['is_pdc'] = (result.server_type & nbt.NBT_SERVER_PDC) != 0 # Netlogon response doesn't contain SID of the domain. - # We need to do rootDSE search with LDAP_SERVER_EXTENDED_DN_OID control to reveal the SID + # We need to do rootDSE search with LDAP_SERVER_EXTENDED_DN_OID + # control to reveal the SID ldap_uri = 'ldap://%s' % (result.pdc_dns_name) conn = _ldap.initialize(ldap_uri) conn.set_option(_ldap.OPT_SERVER_CONTROLS, [ExtendedDNControl()]) @@ -908,7 +971,7 @@ class TrustDomainInstance(object): except _ldap.LDAPError as e: root_logger.error( "LDAP error when connecting to %(host)s: %(error)s" % - dict(host=unicode(result.pdc_name), error=str(e))) + dict(host=unicode(result.pdc_name), error=str(e))) except KeyError as e: root_logger.error("KeyError: {err}, LDAP entry from {host} " "returned malformed. Your DNS might be " @@ -930,8 +993,11 @@ class TrustDomainInstance(object): objectAttribute = lsa.ObjectAttribute() objectAttribute.sec_qos = lsa.QosInfo() try: - self._policy_handle = self._pipe.OpenPolicy2(u"", objectAttribute, security.SEC_FLAG_MAXIMUM_ALLOWED) - result = self._pipe.QueryInfoPolicy2(self._policy_handle, lsa.LSA_POLICY_INFO_DNS) + self._policy_handle = \ + self._pipe.OpenPolicy2(u"", objectAttribute, + security.SEC_FLAG_MAXIMUM_ALLOWED) + result = self._pipe.QueryInfoPolicy2(self._policy_handle, + lsa.LSA_POLICY_INFO_DNS) except RuntimeError as e: num, message = e.args # pylint: disable=unpacking-non-sequence raise assess_dcerpc_exception(num=num, message=message) @@ -944,7 +1010,8 @@ class TrustDomainInstance(object): self.info['dc'] = remote_host try: - result = self._pipe.QueryInfoPolicy2(self._policy_handle, lsa.LSA_POLICY_INFO_ROLE) + result = self._pipe.QueryInfoPolicy2(self._policy_handle, + lsa.LSA_POLICY_INFO_ROLE) except RuntimeError as e: num, message = e.args # pylint: disable=unpacking-non-sequence raise assess_dcerpc_exception(num=num, message=message) @@ -958,18 +1025,18 @@ class TrustDomainInstance(object): clear_value.size = len(password_blob) clear_value.password = password_blob - clear_authentication_information = drsblobs.AuthenticationInformation() - clear_authentication_information.LastUpdateTime = samba.unix2nttime(int(time.time())) - clear_authentication_information.AuthType = lsa.TRUST_AUTH_TYPE_CLEAR - clear_authentication_information.AuthInfo = clear_value + clear_authinfo = drsblobs.AuthenticationInformation() + clear_authinfo.LastUpdateTime = samba.unix2nttime(int(time.time())) + clear_authinfo.AuthType = lsa.TRUST_AUTH_TYPE_CLEAR + clear_authinfo.AuthInfo = clear_value - authentication_information_array = drsblobs.AuthenticationInformationArray() - authentication_information_array.count = 1 - authentication_information_array.array = [clear_authentication_information] + authinfo_array = drsblobs.AuthenticationInformationArray() + authinfo_array.count = 1 + authinfo_array.array = [clear_authinfo] outgoing = drsblobs.trustAuthInOutBlob() outgoing.count = 1 - outgoing.current = authentication_information_array + outgoing.current = authinfo_array confounder = [3]*512 for i in range(512): @@ -983,7 +1050,8 @@ class TrustDomainInstance(object): trustpass_blob = ndr_pack(trustpass) - encrypted_trustpass = arcfour_encrypt(self._pipe.session_key, trustpass_blob) + encrypted_trustpass = arcfour_encrypt(self._pipe.session_key, + trustpass_blob) auth_blob = lsa.DATA_BUF2() auth_blob.size = len(encrypted_trustpass) @@ -993,7 +1061,6 @@ class TrustDomainInstance(object): auth_info.auth_blob = auth_blob self.auth_info = auth_info - def generate_ftinfo(self, another_domain): """ Generates TrustDomainInfoFullInfo2Internal structure @@ -1032,27 +1099,38 @@ class TrustDomainInstance(object): # smbd already has the information about itself ldname = lsa.StringLarge() ldname.string = another_domain.info['dns_domain'] - collision_info = self._pipe.lsaRSetForestTrustInformation(self._policy_handle, - ldname, - lsa.LSA_FOREST_TRUST_DOMAIN_INFO, - ftinfo, 0) - if collision_info: - root_logger.error("When setting forest trust information, got collision info back:\n%s" % (ndr_print(collision_info))) + ftlevel = lsa.LSA_FOREST_TRUST_DOMAIN_INFO + # RSetForestTrustInformation returns collision information + # for trust topology + cinfo = self._pipe.lsaRSetForestTrustInformation( + self._policy_handle, + ldname, + ftlevel, + ftinfo, 0) + if cinfo: + root_logger.error("When setting forest trust information, " + "got collision info back:\n%s" + % (ndr_print(cinfo))) except RuntimeError as e: - # We can ignore the error here -- setting up name suffix routes may fail + # We can ignore the error here -- + # setting up name suffix routes may fail pass - def establish_trust(self, another_domain, trustdom_secret, trust_type='bidirectional', trust_external=False): + def establish_trust(self, another_domain, trustdom_secret, + trust_type='bidirectional', trust_external=False): """ Establishes trust between our and another domain - Input: another_domain -- instance of TrustDomainInstance, initialized with #retrieve call + Input: another_domain -- instance of TrustDomainInstance, + initialized with #retrieve call trustdom_secret -- shared secred used for the trust """ if self.info['name'] == another_domain.info['name']: # Check that NetBIOS names do not clash raise errors.ValidationError(name=u'AD Trust Setup', - error=_('the IPA server and the remote domain cannot share the same ' - 'NetBIOS name: %s') % self.info['name']) + error=_('the IPA server and the ' + 'remote domain cannot share ' + 'the same NetBIOS name: %s') + % self.info['name']) self.generate_auth(trustdom_secret) @@ -1071,8 +1149,12 @@ class TrustDomainInstance(object): try: dname = lsa.String() dname.string = another_domain.info['dns_domain'] - res = self._pipe.QueryTrustedDomainInfoByName(self._policy_handle, dname, lsa.LSA_TRUSTED_DOMAIN_INFO_FULL_INFO) - self._pipe.DeleteTrustedDomain(self._policy_handle, res.info_ex.sid) + res = self._pipe.QueryTrustedDomainInfoByName( + self._policy_handle, + dname, + lsa.LSA_TRUSTED_DOMAIN_INFO_FULL_INFO) + self._pipe.DeleteTrustedDomain(self._policy_handle, + res.info_ex.sid) except RuntimeError as e: num, message = e.args # pylint: disable=unpacking-non-sequence # Ignore anything but access denied (NT_STATUS_ACCESS_DENIED) @@ -1080,7 +1162,10 @@ class TrustDomainInstance(object): raise access_denied_error try: - trustdom_handle = self._pipe.CreateTrustedDomainEx2(self._policy_handle, info, self.auth_info, security.SEC_STD_DELETE) + trustdom_handle = self._pipe.CreateTrustedDomainEx2( + self._policy_handle, + info, self.auth_info, + security.SEC_STD_DELETE) except RuntimeError as e: num, message = e.args # pylint: disable=unpacking-non-sequence raise assess_dcerpc_exception(num=num, message=message) @@ -1089,13 +1174,19 @@ class TrustDomainInstance(object): # trust settings. Samba insists this has to be done with LSA # OpenTrustedDomain* calls, it is not enough to have a handle # returned by the CreateTrustedDomainEx2 call. - trustdom_handle = self._pipe.OpenTrustedDomainByName(self._policy_handle, dname, security.SEC_FLAG_MAXIMUM_ALLOWED) + trustdom_handle = self._pipe.OpenTrustedDomainByName( + self._policy_handle, + dname, + security.SEC_FLAG_MAXIMUM_ALLOWED) try: - infoclass = lsa.TrustDomainInfoSupportedEncTypes() - infoclass.enc_types = security.KERB_ENCTYPE_RC4_HMAC_MD5 - infoclass.enc_types |= security.KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 - infoclass.enc_types |= security.KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96 - self._pipe.SetInformationTrustedDomain(trustdom_handle, lsa.LSA_TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES, infoclass) + infocls = lsa.TrustDomainInfoSupportedEncTypes() + infocls.enc_types = security.KERB_ENCTYPE_RC4_HMAC_MD5 + infocls.enc_types |= security.KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 + infocls.enc_types |= security.KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96 + self._pipe.SetInformationTrustedDomain( + trustdom_handle, + lsa.LSA_TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES, + infocls) except RuntimeError as e: # We can ignore the error here -- changing enctypes is for # improved security but the trust will work with default values as @@ -1105,13 +1196,16 @@ class TrustDomainInstance(object): if not trust_external: try: - info = self._pipe.QueryTrustedDomainInfo(trustdom_handle, - lsa.LSA_TRUSTED_DOMAIN_INFO_INFO_EX) + info = self._pipe.QueryTrustedDomainInfo( + trustdom_handle, + lsa.LSA_TRUSTED_DOMAIN_INFO_INFO_EX) info.trust_attributes |= lsa.LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE - self._pipe.SetInformationTrustedDomain(trustdom_handle, - lsa.LSA_TRUSTED_DOMAIN_INFO_INFO_EX, info) + self._pipe.SetInformationTrustedDomain( + trustdom_handle, + lsa.LSA_TRUSTED_DOMAIN_INFO_INFO_EX, info) except RuntimeError as e: - root_logger.error('unable to set trust transitivity status: %s' % (str(e))) + root_logger.error( + 'unable to set trust transitivity status: %s' % (str(e))) if self.info['is_pdc'] or trust_external: self.update_ftinfo(another_domain) @@ -1119,12 +1213,13 @@ class TrustDomainInstance(object): def verify_trust(self, another_domain): def retrieve_netlogon_info_2(logon_server, domain, function_code, data): try: - netr_pipe = netlogon.netlogon(domain.binding, domain.parm, domain.creds) - result = netr_pipe.netr_LogonControl2Ex(logon_server=logon_server, + netr_pipe = netlogon.netlogon(domain.binding, + domain.parm, domain.creds) + result = netr_pipe.netr_LogonControl2Ex( + logon_server=logon_server, function_code=function_code, level=2, - data=data - ) + data=data) return result except RuntimeError as e: num, message = e.args # pylint: disable=unpacking-non-sequence @@ -1135,9 +1230,11 @@ class TrustDomainInstance(object): another_domain.info['dns_domain']) if result and result.flags and netlogon.NETLOGON_VERIFY_STATUS_RETURNED: - if result.pdc_connection_status[0] != 0 and result.tc_connection_status[0] != 0: + if result.pdc_connection_status[0] != 0 and \ + result.tc_connection_status[0] != 0: if result.pdc_connection_status[1] == "WERR_ACCESS_DENIED": - # Most likely AD DC hit another IPA replica which yet has no trust secret replicated + # Most likely AD DC hit another IPA replica which + # yet has no trust secret replicated # Sleep and repeat again self.validation_attempts += 1 @@ -1176,23 +1273,23 @@ class TrustDomainInstance(object): def fetch_domains(api, mydomain, trustdomain, creds=None, server=None): trust_flags = dict( - NETR_TRUST_FLAG_IN_FOREST = 0x00000001, - NETR_TRUST_FLAG_OUTBOUND = 0x00000002, - NETR_TRUST_FLAG_TREEROOT = 0x00000004, - NETR_TRUST_FLAG_PRIMARY = 0x00000008, - NETR_TRUST_FLAG_NATIVE = 0x00000010, - NETR_TRUST_FLAG_INBOUND = 0x00000020, - NETR_TRUST_FLAG_MIT_KRB5 = 0x00000080, - NETR_TRUST_FLAG_AES = 0x00000100) + NETR_TRUST_FLAG_IN_FOREST=0x00000001, + NETR_TRUST_FLAG_OUTBOUND=0x00000002, + NETR_TRUST_FLAG_TREEROOT=0x00000004, + NETR_TRUST_FLAG_PRIMARY=0x00000008, + NETR_TRUST_FLAG_NATIVE=0x00000010, + NETR_TRUST_FLAG_INBOUND=0x00000020, + NETR_TRUST_FLAG_MIT_KRB5=0x00000080, + NETR_TRUST_FLAG_AES=0x00000100) trust_attributes = dict( - NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x00000001, - NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x00000002, - NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x00000004, - NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x00000008, - NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x00000010, - NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x00000020, - NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x00000040) + NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE=0x00000001, + NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY=0x00000002, + NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN=0x00000004, + NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE=0x00000008, + NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION=0x00000010, + NETR_TRUST_ATTRIBUTE_WITHIN_FOREST=0x00000020, + NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL=0x00000040) def communicate(td): td.init_lsa_pipe(td.info['dc']) @@ -1314,7 +1411,8 @@ class TrustDomainJoins(object): ld.retrieve(installutils.get_fqdn()) self.local_domain = ld - def populate_remote_domain(self, realm, realm_server=None, realm_admin=None, realm_passwd=None): + def populate_remote_domain(self, realm, realm_server=None, + realm_admin=None, realm_passwd=None): def get_instance(self): # Fetch data from foreign domain using password only rd = TrustDomainInstance('') @@ -1330,7 +1428,8 @@ class TrustDomainJoins(object): if realm_server is None: rd.retrieve_anonymously(realm, discover_srv=True, search_pdc=True) else: - rd.retrieve_anonymously(realm_server, discover_srv=False, search_pdc=True) + rd.retrieve_anonymously(realm_server, + discover_srv=False, search_pdc=True) rd.read_only = True if realm_admin and realm_passwd: if 'name' in rd.info: @@ -1339,12 +1438,14 @@ class TrustDomainJoins(object): # realm admin is in DOMAIN\user format # strip DOMAIN part as we'll enforce the one discovered realm_admin = names[-1] - auth_string = u"%s\%s%%%s" % (rd.info['name'], realm_admin, realm_passwd) + auth_string = u"%s\%s%%%s" \ + % (rd.info['name'], realm_admin, realm_passwd) td = get_instance(self) td.creds.parse_string(auth_string) td.creds.set_workstation(self.local_domain.hostname) if realm_server is None: - # we must have rd.info['dns_hostname'] then, part of anonymous discovery + # we must have rd.info['dns_hostname'] then + # as it is part of the anonymous discovery td.retrieve(rd.info['dns_hostname']) else: td.retrieve(realm_server) @@ -1358,8 +1459,8 @@ class TrustDomainJoins(object): """ Generate list of records for forest trust information about our realm domains. Note that the list generated currently - includes only top level domains, no exclusion domains, and no TDO objects - as we handle the latter in a separate way + includes only top level domains, no exclusion domains, and + no TDO objects as we handle the latter in a separate way """ if self.local_domain.read_only: return @@ -1367,10 +1468,15 @@ class TrustDomainJoins(object): self.local_domain.ftinfo_records = [] realm_domains = self.api.Command.realmdomains_show()['result'] - # Use realmdomains' modification timestamp to judge records last update time - entry = self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp']) + # Use realmdomains' modification timestamp + # to judge records' last update time + entry = self.api.Backend.ldap2.get_entry( + realm_domains['dn'], ['modifyTimestamp']) # Convert the timestamp to Windows 64-bit timestamp format - trust_timestamp = long(time.mktime(entry['modifytimestamp'][0].timetuple())*1e7+116444736000000000) + trust_timestamp = long( + time.mktime( + entry.single_value.get('modifytimestamp').timetuple() + )*1e7+116444736000000000) for dom in realm_domains['associateddomain']: ftinfo = dict() @@ -1379,7 +1485,8 @@ class TrustDomainJoins(object): ftinfo['rec_type'] = lsa.LSA_FOREST_TRUST_TOP_LEVEL_NAME self.local_domain.ftinfo_records.append(ftinfo) - def join_ad_full_credentials(self, realm, realm_server, realm_admin, realm_passwd, trust_type): + def join_ad_full_credentials(self, realm, realm_server, realm_admin, + realm_passwd, trust_type): if not self.configured: return None @@ -1392,24 +1499,33 @@ class TrustDomainJoins(object): ) trust_external = bool(self.__allow_behavior & TRUST_JOIN_EXTERNAL) - if self.remote_domain.info['dns_domain'] != self.remote_domain.info['dns_forest']: + if self.remote_domain.info['dns_domain'] != \ + self.remote_domain.info['dns_forest']: if not trust_external: - raise errors.NotAForestRootError(forest=self.remote_domain.info['dns_forest'], - domain=self.remote_domain.info['dns_domain']) + raise errors.NotAForestRootError( + forest=self.remote_domain.info['dns_forest'], + domain=self.remote_domain.info['dns_domain']) if not self.remote_domain.read_only: trustdom_pass = samba.generate_random_password(128, 128) self.get_realmdomains() self.remote_domain.establish_trust(self.local_domain, - trustdom_pass, trust_type, trust_external) + trustdom_pass, + trust_type, trust_external) self.local_domain.establish_trust(self.remote_domain, - trustdom_pass, trust_type, trust_external) - # if trust is inbound, we don't need to verify it because AD DC will respond - # with WERR_NO_SUCH_DOMAIN -- in only does verification for outbound trusts. + trustdom_pass, + trust_type, trust_external) + # if trust is inbound, we don't need to verify it because + # AD DC will respond with WERR_NO_SUCH_DOMAIN -- + # it only does verification for outbound trusts. result = True if trust_type == TRUST_BIDIRECTIONAL: result = self.remote_domain.verify_trust(self.local_domain) - return dict(local=self.local_domain, remote=self.remote_domain, verified=result) + return dict( + local=self.local_domain, + remote=self.remote_domain, + verified=result + ) return None def join_ad_ipa_half(self, realm, realm_server, trustdom_passwd, trust_type): @@ -1420,11 +1536,18 @@ class TrustDomainJoins(object): self.populate_remote_domain(realm, realm_server, realm_passwd=None) trust_external = bool(self.__allow_behavior & TRUST_JOIN_EXTERNAL) - if self.remote_domain.info['dns_domain'] != self.remote_domain.info['dns_forest']: + if self.remote_domain.info['dns_domain'] != \ + self.remote_domain.info['dns_forest']: if not trust_external: - raise errors.NotAForestRootError(forest=self.remote_domain.info['dns_forest'], - domain=self.remote_domain.info['dns_domain']) + raise errors.NotAForestRootError( + forest=self.remote_domain.info['dns_forest'], + domain=self.remote_domain.info['dns_domain']) self.local_domain.establish_trust(self.remote_domain, - trustdom_passwd, trust_type, trust_external) - return dict(local=self.local_domain, remote=self.remote_domain, verified=False) + trustdom_passwd, + trust_type, trust_external) + return dict( + local=self.local_domain, + remote=self.remote_domain, + verified=False + ) -- 2.7.4 -------------- next part -------------- From 90b9e338994255155294614e8c21ca070c59e1a6 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 15 Aug 2016 18:14:00 +0300 Subject: [PATCH 09/10] trust: automatically resolve DNS trust conflicts for triangle trusts For configuration where: - AD example.com trusts IPA at ipa.example.com - AD example.org trusts AD example.com - a trust is tried to be established between ipa.example.com and example.org, there will be a trust topology conflict detected by example.org domain controller because ipa.example.com DNS namespace overlaps with example.com DNS namespace. This type of trust topology conflict is documented in MS-ADTS 6.1.6.9.3.2 "Building Well-Formed msDS-TrustForestTrustInfo Message". A similar conflict can arise for SID and NetBIOS namespaces. However, unlike SID and NetBIOS namespaces, we can solve DNS namespace conflict automatically if there are administrative credentials for example.org available. A manual sequence to solve the DNS namespace conflict is described in https://msdn.microsoft.com/it-it/library/cc786254%28v=ws.10%29.aspx. This sequence boils down to the following steps: 1. As an administrator of the example.org, you need to add an exclusion entry for ipa.example.com in the properties of the trust to example.com 2. Establish trust between ipa.example.com and example.org It is important to add the exclusion entry before step 4 or there will be conflict recorded which cannot be cleared easily right now due to a combination of bugs in both IPA and Active Directory. This patchset implements automated solution for the case when we have access to the example.org's administrator credentials: 1. Attempt to establish trust and update trust topology information. 2. If trust topology conflict is detected as result of (1): 2.1. Fetch trust topology infromation for the conflicting forest trust 2.2. Add exclusion entry to our domain to the trust topology obtained in (2.1) 2.3. Update trust topology for the conflicting forest trust 3. Re-establish trust between ipa.example.com and example.org We cannot do the same for shared secret trust and for external trust, though: 1. For shared secret trust we don't have administrative credentials in the forest reporting the conflict 2. For the external trust we cannot set topology information due to MS-LSAD 3.1.4.7.16 because external trust is non-transitive by definition and thus setting topology information will fail. To test this logic one can use two Samba AD forests with FreeIPA using a sub-domain of one of them. Fixes: https://fedorahosted.org/freeipa/ticket/6076 --- ipalib/errors.py | 34 +++++++++ ipaserver/dcerpc.py | 214 +++++++++++++++++++++++++++++++++++++++++++++------- 2 files changed, 220 insertions(+), 28 deletions(-) diff --git a/ipalib/errors.py b/ipalib/errors.py index 7b4f15d..0e351b5 100644 --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -866,6 +866,40 @@ class NotAForestRootError(InvocationError): errno = 3016 format = _("Domain '%(domain)s' is not a root domain for forest '%(forest)s'") +class TrustTopologyConflictError(InvocationError): + """ + **3017** Raised when an attempt to establish trust fails with a topology + conflict against another forest the target forest trusts + + For example: + + >>> raise TrustTopologyConflictError(forest='example.test', + conflict='my.ad.test', + domains=['ad.test']) + Traceback (most recent call last): + ... + TrustTopologyConflictError: Forest 'example.test' has existing trust to forest(s) ['ad.test'] which prevents a trust to 'my.ad.test' + """ + + errno = 3017 + format = _("Forest '%(forest)s' has existing trust to forest(s) %(domains)s which prevents a trust to '%(conflict)s'") + +class TrustTopologyConflictSolved(InvocationError): + """ + **3018** Raised when an attempt to establish trust fails with a topology + conflict against another forest the target forest trusts + + For example: + + >>> raise TrustTopologyConflictError(forest='example.test', + conflict='my.ad.test') + Traceback (most recent call last): + ... + TrustTopologyConflictSolved: When adding forest trust between 'my.ad.test' and 'example.test', a topology conflict was solved + """ + + errno = 3018 + format = _("When adding forest trust between '%(conflict)s' and '%(forest)s', a topology conflict was solved") ############################################################################## # 4000 - 4999: Execution errors diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 19be6bf..e9e9e1e 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -1,7 +1,7 @@ # Authors: # Alexander Bokovoy # -# Copyright (C) 2011 Red Hat +# Copyright (C) 2011-2016 Red Hat # see file 'COPYING' for use and warranty information # # Portions (C) Andrew Tridgell, Andrew Bartlett @@ -1087,34 +1087,168 @@ class TrustDomainInstance(object): info.entries = ftinfo_records return info + def clear_ftinfo_conflict(self, another_domain, cinfo): + """ + Attempt to clean up the forest trust collisions + + This code tries to perform intelligent job of going + over individual collisions and making exclusion entries + for affected IPA namespaces. + + There are three possible conflict configurations: + - conflict of DNS namespace (TLN conflict, LSA_TLN_DISABLED_CONFLICT) + - conflict of SID namespace (LSA_SID_DISABLED_CONFLICT) + - conflict of NetBIOS namespace (LSA_NB_DISABLED_CONFLICT) + + we only can handle TLN conflicts because (a) excluding SID namespace + is not possible and (b) excluding NetBIOS namespace not possible. + These two types of conflicts should result in trust-add CLI error + + These conflicts can come from external source (another forest) or + from internal source (another domain in the same forest). We only + can fix the problems with another forest. + + To resolve TLN conflict we need to do following: + 1. Retrieve forest trust information for the forest we conflict on + 2. Add an exclusion entry for IPA DNS namespace to it + 3. Set forest trust information for the forest we conflict on + 4. Re-try establishing trust to the original forest + + This all can only be done under privileges of Active Directory admin + that can change forest trusts. If we cannot have those privileges, + the work has to be done manually in the Windows UI for + 'Active Directory Domains and Trusts' by the administrator of the + original forest. + """ + + # Number of conflicts, entries for unsolved conflicts + result = [cinfo.count, []] + + # In the code below: + # self -- the forest we establish trust to + # another_domain -- a forest that establishes trust to 'self' + # cinfo -- lsa_ForestTrustCollisionInfo structure that contains + # set of of lsa_ForestTrustCollisionRecord structures + trust_timestamp = long(time.time()*1e7+116444736000000000) + + # Collision information contains entries for specific trusted domains + # we collide with. Look into TLN collisions and add a TLN exclusion + # entry to the specific domain trust. + root_logger.error("Attempt to solve forest trust topology conflicts") + for rec in cinfo.entries: + if rec.type == lsa.LSA_FOREST_TRUST_COLLISION_TDO: + dominfo = self._pipe.lsaRQueryForestTrustInformation( + self._policy_handle, + rec.name, + lsa.LSA_FOREST_TRUST_DOMAIN_INFO) + + # Oops, we were unable to retrieve trust topology for this + # trusted domain (forest). + if not dominfo: + result[1].append(rec) + root_logger.error("Unable to resolve conflict for " + "DNS domain %s in the forest %s " + "for domain trust %s. Trust cannot " + "be established unless this conflict " + "is fixed manually." + % (another_domain.info['dns_domain'], + self.info['dns_domain'], + rec.name.string)) + continue + + # Copy over the entries, extend with TLN exclusion + entries = [] + for e in dominfo.entries: + e1 = lsa.ForestTrustRecord() + e1.type = e.type + e1.flags = e.flags + e1.time = e.time + e1.forest_trust_data = e.forest_trust_data + entries.append(e1) + + # Create TLN exclusion record + record = lsa.ForestTrustRecord() + record.type = lsa.LSA_FOREST_TRUST_TOP_LEVEL_NAME_EX + record.flags = 0 + record.time = trust_timestamp + record.forest_trust_data.string = \ + another_domain.info['dns_domain'] + entries.append(record) + + fti = lsa.ForestTrustInformation() + fti.count = len(entries) + fti.entries = entries + + # Update the forest trust information now + ldname = lsa.StringLarge() + ldname.string = rec.name.string + cninfo = self._pipe.lsaRSetForestTrustInformation( + self._policy_handle, + ldname, + lsa.LSA_FOREST_TRUST_DOMAIN_INFO, + fti, 0) + if cninfo: + result[1].append(rec) + root_logger.error("When defining exception for DNS " + "domain %s in forest %s for " + "trusted forest %s, " + "got collision info back:\n%s" + % (another_domain.info['dns_domain'], + self.info['dns_domain'], + rec.name.string, + ndr_print(cninfo))) + else: + result[1].append(rec) + root_logger.error("Unable to resolve conflict for " + "DNS domain %s in the forest %s " + "for in-forest domain %s. Trust cannot " + "be established unless this conflict " + "is fixed manually." + % (conflict_type[rec.type], + another_domain.info['dns_domain'], + self.info['dns_domain'], + rec.name.string)) + + if len(result[1]) == 0: + root_logger.error("Successfully solved all conflicts") + + return result + + def update_ftinfo(self, another_domain): """ Updates forest trust information in this forest corresponding to the another domain's information. """ - try: - if another_domain.ftinfo_records: - ftinfo = self.generate_ftinfo(another_domain) - # Set forest trust information -- we do it only against AD DC as - # smbd already has the information about itself - ldname = lsa.StringLarge() - ldname.string = another_domain.info['dns_domain'] - ftlevel = lsa.LSA_FOREST_TRUST_DOMAIN_INFO - # RSetForestTrustInformation returns collision information - # for trust topology - cinfo = self._pipe.lsaRSetForestTrustInformation( - self._policy_handle, - ldname, - ftlevel, - ftinfo, 0) - if cinfo: - root_logger.error("When setting forest trust information, " - "got collision info back:\n%s" - % (ndr_print(cinfo))) - except RuntimeError as e: - # We can ignore the error here -- - # setting up name suffix routes may fail - pass + if another_domain.ftinfo_records: + ftinfo = self.generate_ftinfo(another_domain) + # Set forest trust information -- we do it only against AD DC as + # smbd already has the information about itself + ldname = lsa.StringLarge() + ldname.string = another_domain.info['dns_domain'] + ftlevel = lsa.LSA_FOREST_TRUST_DOMAIN_INFO + # RSetForestTrustInformation returns collision information + # for trust topology + cinfo = self._pipe.lsaRSetForestTrustInformation( + self._policy_handle, + ldname, + ftlevel, + ftinfo, 0) + if cinfo: + root_logger.error("When setting forest trust information, " + "got collision info back:\n%s" + % (ndr_print(cinfo))) + res = self.clear_ftinfo_conflict(another_domain, cinfo) + if len(res[1]) != 0: + domains = [x.name.string for x in res[1]] + raise errors.TrustTopologyConflictError( + target=self.info['dns_domain'], + conflict=another_domain.info['dns_domain'], + domains=domains) + else: + raise errors.TrustTopologyConflictSolved( + target=self.info['dns_domain'], + conflict=another_domain.info['dns_domain']) def establish_trust(self, another_domain, trustdom_secret, trust_type='bidirectional', trust_external=False): @@ -1207,7 +1341,19 @@ class TrustDomainInstance(object): root_logger.error( 'unable to set trust transitivity status: %s' % (str(e))) - if self.info['is_pdc'] or trust_external: + # Updating forest trust info may fail + # If it failed due to topology conflict, it may be fixed automatically + # update_ftinfo() will through exceptions in that case + # Note that MS-LSAD 3.1.4.7.16 says: + # ------------------------- + # The server MUST also make sure that the trust attributes associated + # with the trusted domain object referenced by the TrustedDomainName + # parameter has the TRUST_ATTRIBUTE_FOREST_TRANSITIVE set. + # If the attribute is not present, the server MUST return + # STATUS_INVALID_PARAMETER. + # ------------------------- + # Thus, we must not update forest trust info for the external trust + if self.info['is_pdc'] and not trust_external: self.update_ftinfo(another_domain) def verify_trust(self, another_domain): @@ -1509,9 +1655,21 @@ class TrustDomainJoins(object): if not self.remote_domain.read_only: trustdom_pass = samba.generate_random_password(128, 128) self.get_realmdomains() - self.remote_domain.establish_trust(self.local_domain, - trustdom_pass, - trust_type, trust_external) + + # Establishing trust may throw an exception for topology + # conflict. If it was solved, re-establish the trust again + # Otherwise let the CLI to display a message about the conflict + try: + self.remote_domain.establish_trust(self.local_domain, + trustdom_pass, + trust_type, trust_external) + except errors.TrustTopologyConflictSolved as e: + # we solved topology conflict, retry again + self.remote_domain.establish_trust(self.local_domain, + trustdom_pass, + trust_type, trust_external) + + # For local domain we don't set topology information self.local_domain.establish_trust(self.remote_domain, trustdom_pass, trust_type, trust_external) -- 2.7.4 -------------- next part -------------- From 08dd95a7ff9c39ae2bfe167b51934666b550b57c Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 15 Aug 2016 18:32:25 +0300 Subject: [PATCH 10/10] trust: make sure external trust topology is correctly rendered When external trust is established, it is by definition is non-transitive: it is not possible to obtain Kerberos tickets to any service outside the trusted domain. Reflect this reality by only accepting UPN suffixes from the external trust -- since the trusted domain is a part of another forest and UPN suffixes are forest-wide, there are could be user accounts in the trusted domain that use forest-wide UPN suffix but it will be impossible to reach the forest root via the externally trusted domain. https://fedorahosted.org/freeipa/ticket/6021 --- ipaserver/dcerpc.py | 2 +- ipaserver/plugins/trust.py | 28 +++++++++++++++++----------- 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index e9e9e1e..777c311 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -1443,7 +1443,7 @@ def fetch_domains(api, mydomain, trustdomain, creds=None, server=None): # Older FreeIPA versions used netr_DsrEnumerateDomainTrusts call # but it doesn't provide information about non-domain UPNs associated # with the forest, thus we have to use netr_DsRGetForestTrustInformation - domains = netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], '', 0) + domains = netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], None, 0) return domains domains = None diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py index f90d9c1..b9d9b12 100644 --- a/ipaserver/plugins/trust.py +++ b/ipaserver/plugins/trust.py @@ -1663,6 +1663,23 @@ def add_new_domains_from_trust(myapi, trustinstance, trust_entry, domains, **opt for x, y in six.iteritems(domains['suffixes']) if x not in domains['domains']) + try: + dn = myapi.Object.trust.get_dn(trust_name, trust_type=u'ad') + ldap = myapi.Backend.ldap2 + entry = ldap.get_entry(dn) + tlns = entry.get('ipantadditionalsuffixes', []) + tlns.extend(x for x in suffixes if x not in tlns) + entry['ipantadditionalsuffixes'] = tlns + ldap.update_entry(entry) + except errors.EmptyModlist: + pass + + is_nontransitive = int(trust_entry.get('ipanttrustattributes', + [0])[0]) & LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE + + if is_nontransitive: + return result + for dom in six.itervalues(domains['domains']): dom['trust_type'] = u'ad' try: @@ -1690,17 +1707,6 @@ def add_new_domains_from_trust(myapi, trustinstance, trust_entry, domains, **opt # Ignore updating duplicate entries pass - try: - dn = myapi.Object.trust.get_dn(trust_name, trust_type=u'ad') - ldap = myapi.Backend.ldap2 - entry = ldap.get_entry(dn) - tlns = entry.get('ipantadditionalsuffixes', []) - tlns.extend(x for x in suffixes if x not in tlns) - entry['ipantadditionalsuffixes'] = tlns - ldap.update_entry(entry) - except errors.EmptyModlist: - pass - return result -- 2.7.4 From ftweedal at redhat.com Tue Aug 16 00:07:18 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 16 Aug 2016 10:07:18 +1000 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <0b57369b-57d6-4567-1a4d-ae3c63ba1bbf@redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> <6e5f6d1b-5629-f3b1-fe5d-24593795bf65@redhat.com> <20160815131625.GO23927@dhcp-40-8.bne.redhat.com> <35967055-8dc6-58e2-3c15-2b1187da3435@redhat.com> <20160815135432.GP23927@dhcp-40-8.bne.redhat.com> <0b57369b-57d6-4567-1a4d-ae3c63ba1bbf@redhat.com> Message-ID: <20160816000718.GQ23927@dhcp-40-8.bne.redhat.com> On Mon, Aug 15, 2016 at 03:58:40PM +0200, Petr Spacek wrote: > On 15.8.2016 15:54, Fraser Tweedale wrote: > > On Mon, Aug 15, 2016 at 03:31:20PM +0200, Petr Spacek wrote: > >> On 15.8.2016 15:16, Fraser Tweedale wrote: > >>> On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote: > >>>> On 2.8.2016 05:57, Fraser Tweedale wrote: > >>>>>>> Hah! This is what I get for thinking I know what the output has to look > >>>>>>> like, and not testing all the way through to requesting the cert. I'll > >>>>>>> change the profile to generate a subject with CN= instead of UID=. Updated > >>>>>>> patch is attached. Unfortunately these rules are only updated at > >>>>>>> ipa-server-install time, so if you'd like to fix it without reinstalling: > >>>>>>> > >>>>> (Tangential commentary...) Yeah, currently cert-request demands the > >>>>> CN. There is a design to relax the requirement to handle empty > >>>>> subject names (look at SAN only). IMO it would make sense to accept > >>>>> other "obvious" mappings in Subject DN like accepting UID instead of > >>>>> CN for user subjects, but that would be a separate RFE. Noone has > >>>>> actually asked for it yet :) > >>>> > >>>> Side-note: > >>>> I thought that subject format is enforced by certificate profile on server. > >>>> Am I wrong? > >>>> > >>> You are right - what I suggested above would (today) require a > >>> custom profile. > >> > >> Sooo... > >> can we just relax existing profiles not to require CN= but accept SAN-only CSRs? > >> > >> :-) > >> > > That is absolutely going to happen as part of > > http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance :) > > Good! > > Is it still targeting 4.4.x? > It's not going to make it. From ftweedal at redhat.com Tue Aug 16 05:24:02 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 16 Aug 2016 15:24:02 +1000 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> <885c4c72-6e8a-4220-b25e-f577612368d2@redhat.com> <20160809144716.GA23927@dhcp-40-8.bne.redhat.com> Message-ID: <20160816052401.GR23927@dhcp-40-8.bne.redhat.com> On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > On 9.8.2016 16:47, Fraser Tweedale wrote: > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > > > Hi, > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > Please review the attached patch with adds --certificate-out and > > > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > > > > > Note that --certificate-chain-out currently writes a bogus file due > > > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > 1) The client-side *-out options should be defined on the client side, not > > > > > on the server side. > > > > > > > > > Will option defined on client side be propagated to, and observable > > > > in the ipaserver plugin? The ipaserver plugin needs to observe that > > > > *-out has been requested and executes additional command(s) on that > > > > basis. > > > > > > Is there a reason not to *always* return the certs? > > > > > We hit Dogtag to retrieve them. > > I don't think that's an issue in a -show command. > cert_show is invoked by other commands (cert_find*, cert_show, cert_request, cert_status, ca_del) but these all hit Dogtag anyway so I suppose that's fine. I'll return the cert *and* the chain in separate attributes, unconditionally. > > > > > > > > > > > > > > > > 2) I don't think there should be additional information included in summary > > > > > (and it definitely should not be multi-line). I would rather inform the user > > > > > via an error message when unable to write the files. > > > > > > > > > I was just following the pattern of other commands that write certs, > > > > profile config, etc. Apart from consistency with other commands I > > > > agree that there is no need to have it. So I will remove it. > > > > > > > > > If you think there is an actual value in informing the user about > > > > > successfully writing the files, please use ipalib.messages for the job. > > > > > > > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 would be > > > > > concatenated PEM, as that's the most commonly used format in IPA (in > > > > > installers, there are no cert chains in API commands ATM). > > > > > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > > > or concatenated PEMs, but sometimes they must be concatenated > > > > forward, and othertimes backwards. There is no one size fits all. > > > > > > True, which is exactly why I think we should at least be self-consistent and > > > use concatenated PEM (and multi-value DER over the wire). > > > > > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept > > header). > > > > If we want list-of-PEMs between server and client we have to convert > > on the server. Do we have a good way of doing this without exec'ing > > `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' > > to do the conversion on the server? python-nss does not have PKCS7 > > functions and I am not keen on adding a pyasn1 PKCS7 parser just for > > the sake of pushing bits as list-of-PEMs. > > I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other. > For example, if we added a call to retrieve external CA chain using certs > from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to > PKCS#7 if it was our cert chain format of choice. > > What we can avoid though is executing "openssl pkcs7" to do the conversion - > we can use an approach similar to our DNSSEC code and use python-cffi to > call libcrypto's PKCS#7 conversion routines instead. > I had a look at the OpenSSL API for parsing PKCS #7; now I prefer to exec `openssl' to do the job :) I will transmit DER-encoded PKCS #7 object on the wire; we cannot used multi-valued DER attribute because order is important. Client will convert to PEMs. Should have new patch on list this afternoon. Thanks, Fraser > > > > FWIW, man pages and code suggest that PKCS #7 is accepted in > > installer, etc. > > True, but that's a relatively new feature (since 4.1) and the installer > internally executes "openssl pkcs7" to convert PKCS #7 to list of certs :-) > > > > > > > We can add an option to control the format later, but for now, > > > > Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst > > > > case is an admin has to invoke `openssl pkcs7' and concat the certs > > > > themselves. > > > > > > AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, > > > so I'm afraid the worst case would happen virtually always. > > > > > If you're OK with invoking OpenSSL on the client to convert PKCS #7 > > to list-of-PEMs (similar to what is done in > > ipapython.certdb.NSSDatabase) then we can have the client perform > > the conversion. > > See above. > > > > > > > > > > > > > > > > > 4) Over the wire, the certs should be DER-formatted, as that's the most > > > > > common wire format in other API commands. > > > > > > > > > OK. > > > > > > > > > > > > > > 5) What is the benefit in having the CA cert and the rest of the chain > > > > > separate? For end-entity certs it makes sense to separate the cert from the > > > > > CA chain, but for CA certs, you usually want the full chain, no? > > > > > > > > > If you want to anchor trust directly at a subca (e.g. restrict VPN > > > > login to certs issued by VPN sub-CA) then you often just want the > > > > cert. The chain option does subsume it, at cost of more work for > > > > administrators with this use case. I think it makes sense to keep > > > > both options. > > > > > > Does it? From what you described above, you either want just the sub-CA > > > cert, or the full chain including the sub-CA cert, in which case it might > > > make more sense to have a single --out option and a --chain flag. > > > > > How about --certificate-out which defaults to single cert, but does > > chain (as list-of-PEMs) when --chain flag given. > > > > Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more > > `--out' options. > > +1 > > > > > Thanks, > > Fraser > > > > > -- > Jan Cholasta From jcholast at redhat.com Tue Aug 16 06:10:08 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 16 Aug 2016 08:10:08 +0200 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <20160816052401.GR23927@dhcp-40-8.bne.redhat.com> References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> <885c4c72-6e8a-4220-b25e-f577612368d2@redhat.com> <20160809144716.GA23927@dhcp-40-8.bne.redhat.com> <20160816052401.GR23927@dhcp-40-8.bne.redhat.com> Message-ID: <7ad5a28f-9670-b76a-f100-1a6681ac52e5@redhat.com> On 16.8.2016 07:24, Fraser Tweedale wrote: > On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: >> On 9.8.2016 16:47, Fraser Tweedale wrote: >>> On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: >>>> On 8.8.2016 09:06, Fraser Tweedale wrote: >>>>> On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 8.8.2016 06:34, Fraser Tweedale wrote: >>>>>>> Please review the attached patch with adds --certificate-out and >>>>>>> --certificate-chain-out options to `ca-show' command. >>>>>>> >>>>>>> Note that --certificate-chain-out currently writes a bogus file due >>>>>>> to a bug in Dogtag that will be fixed in this week's build. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/6178 >>>>>> >>>>>> 1) The client-side *-out options should be defined on the client side, not >>>>>> on the server side. >>>>>> >>>>> Will option defined on client side be propagated to, and observable >>>>> in the ipaserver plugin? The ipaserver plugin needs to observe that >>>>> *-out has been requested and executes additional command(s) on that >>>>> basis. >>>> >>>> Is there a reason not to *always* return the certs? >>>> >>> We hit Dogtag to retrieve them. >> >> I don't think that's an issue in a -show command. >> > cert_show is invoked by other commands (cert_find*, cert_show, > cert_request, cert_status, ca_del) but these all hit Dogtag anyway > so I suppose that's fine. I'll return the cert *and* the chain in > separate attributes, unconditionally. > >>> >>>>> >>>>>> >>>>>> 2) I don't think there should be additional information included in summary >>>>>> (and it definitely should not be multi-line). I would rather inform the user >>>>>> via an error message when unable to write the files. >>>>>> >>>>> I was just following the pattern of other commands that write certs, >>>>> profile config, etc. Apart from consistency with other commands I >>>>> agree that there is no need to have it. So I will remove it. >>>>> >>>>>> If you think there is an actual value in informing the user about >>>>>> successfully writing the files, please use ipalib.messages for the job. >>>>>> >>>>>> >>>>>> 3) IMO a better format for the certificate chain than PKCS#7 would be >>>>>> concatenated PEM, as that's the most commonly used format in IPA (in >>>>>> installers, there are no cert chains in API commands ATM). >>>>>> >>>>> Sure, but the main use case isn't IPA. Other apps require PKCS #7 >>>>> or concatenated PEMs, but sometimes they must be concatenated >>>>> forward, and othertimes backwards. There is no one size fits all. >>>> >>>> True, which is exactly why I think we should at least be self-consistent and >>>> use concatenated PEM (and multi-value DER over the wire). >>>> >>> Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept >>> header). >>> >>> If we want list-of-PEMs between server and client we have to convert >>> on the server. Do we have a good way of doing this without exec'ing >>> `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' >>> to do the conversion on the server? python-nss does not have PKCS7 >>> functions and I am not keen on adding a pyasn1 PKCS7 parser just for >>> the sake of pushing bits as list-of-PEMs. >> >> I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other. >> For example, if we added a call to retrieve external CA chain using certs >> from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to >> PKCS#7 if it was our cert chain format of choice. >> >> What we can avoid though is executing "openssl pkcs7" to do the conversion - >> we can use an approach similar to our DNSSEC code and use python-cffi to >> call libcrypto's PKCS#7 conversion routines instead. >> > I had a look at the OpenSSL API for parsing PKCS #7; now I prefer to > exec `openssl' to do the job :) > > I will transmit DER-encoded PKCS #7 object on the wire; we cannot > used multi-valued DER attribute because order is important. Client > will convert to PEMs. Well, my point was not to send PKCS#7 over the wire, so that clients (including 3rd party clients) do not have to convert from PKCS#7 themselves. In fact we can use multi-valued DER - whatever you send over the wire from the server will be received in the exact same order by the client. Even if it wasn't, you can easily restore the order by matching issuer and subject names of the certificates. > > Should have new patch on list this afternoon. > > Thanks, > Fraser > >>> >>> FWIW, man pages and code suggest that PKCS #7 is accepted in >>> installer, etc. >> >> True, but that's a relatively new feature (since 4.1) and the installer >> internally executes "openssl pkcs7" to convert PKCS #7 to list of certs :-) >> >>> >>>>> We can add an option to control the format later, but for now, >>>>> Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst >>>>> case is an admin has to invoke `openssl pkcs7' and concat the certs >>>>> themselves. >>>> >>>> AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, >>>> so I'm afraid the worst case would happen virtually always. >>>> >>> If you're OK with invoking OpenSSL on the client to convert PKCS #7 >>> to list-of-PEMs (similar to what is done in >>> ipapython.certdb.NSSDatabase) then we can have the client perform >>> the conversion. >> >> See above. >> >>> >>>>> >>>>>> >>>>>> 4) Over the wire, the certs should be DER-formatted, as that's the most >>>>>> common wire format in other API commands. >>>>>> >>>>> OK. >>>>> >>>>>> >>>>>> 5) What is the benefit in having the CA cert and the rest of the chain >>>>>> separate? For end-entity certs it makes sense to separate the cert from the >>>>>> CA chain, but for CA certs, you usually want the full chain, no? >>>>>> >>>>> If you want to anchor trust directly at a subca (e.g. restrict VPN >>>>> login to certs issued by VPN sub-CA) then you often just want the >>>>> cert. The chain option does subsume it, at cost of more work for >>>>> administrators with this use case. I think it makes sense to keep >>>>> both options. >>>> >>>> Does it? From what you described above, you either want just the sub-CA >>>> cert, or the full chain including the sub-CA cert, in which case it might >>>> make more sense to have a single --out option and a --chain flag. >>>> >>> How about --certificate-out which defaults to single cert, but does >>> chain (as list-of-PEMs) when --chain flag given. >>> >>> Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more >>> `--out' options. >> >> +1 >> >>> >>> Thanks, >>> Fraser >>> >> >> >> -- >> Jan Cholasta -- Jan Cholasta From slaznick at redhat.com Tue Aug 16 06:21:22 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 16 Aug 2016 08:21:22 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: References: Message-ID: <14a86320-7801-f00e-98bf-14b46f6a4d81@redhat.com> On 08/12/2016 06:48 PM, Petr Spacek wrote: > On 11.8.2016 12:34, Stanislav Laznicka wrote: >> Hello, >> >> I updated the design of the Time-Based HBAC Policies according to the >> discussion we led here earlier. Please check the design page >> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest >> changes are in the Implementation and Feature Management sections. I also >> added a short How to Use section. Thank you for the review! I will add some comments inline. > Nice page! > > On the high level it all makes sense. > > ad LDAP schema > ============== > 1) Why accessTime attribute is MAY in ipaTimeRule object class? > Does it make sense to have the object without accessTime? I do not think so. My idea was that we allow users prepare a few time rule objects before filling them with the actual times. > Also, it could be good to add description attribute to the object class and > incorporate it into commands (including find). > Definitely a good idea, I will work that in. > 2) Besides all this, I spent few minutes in dark history of IPA. The > accessTime attribute was introduced back in 2009 in commit > "55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for IPAv2". > > The commit does not contain any reasoning for the change but I can see that > the attribute is already used as MAY in old object classes ipaHBACRule and > ipaSELinuxUserMap. > > Is any of these a problem? I believe that the accessTime attribute was originally brought to IPA when there was an implementation of time policies for HBAC objects and it's been rotting there ever since those capabilities were removed. We may eventually use a new attribute for storage of the time strings as accessTime by definition is multi-valued which is not what's currently desired (although we may end up with it some day in the future). However, I don't think any other use of accessTime should be a problem as it's been obsoleted for a long time. > Why is it even in ipaSELinuxUserMap object class? I'm sorry to say I have no idea. I used it for what it originally was - a means for storing time strings at HBAC rules. > Commit > 55512dc938eb4a9a6655e473beab587e340af55c does not mention any reason for doing so. > > I cannot see any other problem so the low-level stuff is good and can be > implemented. > > > ad User interface > ================= > We need to polish the user interface so it really usable. > > At least the web interface should contain some shortcuts. E.g. when I'm adding > a new HBAC rule, the "time" section should contain also "something" to > immediately add new time rule so I do not need to go to time rules first and > then go back to HBAC page. > > Similarly, dialog for rule modification should allow to easily change all the > values, warn if time rules is shared, and also have an easy way to > 'disconnect' the time rule, i.e. make a copy of it and edit only the new copy > (instead of the shared original). > > All these are user interface things not affecting the low-level stuff. > > > Maybe you should sat down with some UX designer, talk about these cases and > draw some hand-made pictures. I will add Pavel V. to CC, we may want to discuss this. > I do not believe that this will require any changes in schema so you can > polish SSSD and framework implementation in meantime. > > On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI > functionality (except for the creation of iCalendar strings from options) for > better illustration of the design. > > https://github.com/stlaz/freeipa/tree/timerules_2 > Honestly I did not look at the code today :-) > > Overall, I'm glad to see current proposal. After so many iteration, we reached > something which does not have any glaring problem :-) It definitely felt better to be writing it with all the previous knowledge. Thank you! :-) From lslebodn at redhat.com Tue Aug 16 06:22:03 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 16 Aug 2016 08:22:03 +0200 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> <7d7647ba-d9b0-6be8-18a6-5dbcf178c68c@redhat.com> <7d3265a6-defe-d45c-9491-26d8ec4b3927@redhat.com> <20160815130734.GN23927@dhcp-40-8.bne.redhat.com> Message-ID: <20160816062203.GC16714@10.4.128.1> On (15/08/16 15:30), Petr Spacek wrote: >On 15.8.2016 15:07, Fraser Tweedale wrote: >> On Mon, Aug 15, 2016 at 07:48:22AM +0200, Jan Cholasta wrote: >>> On 12.8.2016 18:57, Petr Spacek wrote: >>>> On 12.8.2016 11:33, Jan Cholasta wrote: >>>>> On 4.8.2016 18:18, Petr Vobornik wrote: >>>>>> On 07/22/2016 07:13 AM, Fraser Tweedale wrote: >>>>>>> On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 14.7.2016 13:44, Fraser Tweedale wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> The attached patch includes SANs in cert-show output. If you have >>>>>>>>> certs with esoteric altnames (especially any that are more than just >>>>>>>>> ASN.1 string types), please test with those certs. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/6022 >>>>>>>> >>>>>>>> I think it would be better to have a separate attribute for each supported >>>>>>>> SAN type rather than cramming everything into subject_alt_name. That way if >>>>>>>> you care only about a single specific type you won't have to go through all >>>>>>>> the values and parse them. Also it would allow you to use param types >>>>>>>> appropriate to the SAN types (DNSNameParam for DNS names, Principal for >>>>>>>> principal names, etc.) >>>>>>>> >>>>>>>> Nitpick: please don't mix moving existing stuff and adding new stuff in a >>>>>>>> single patch. >>>>>>>> >>>>>>> Updated patches attached. >>>>>>> >>>>>>> Patches 0092..0094 are refactors and bugfixes. >>>>>>> Patch 0090-2 is the main feature (depends on 0092..0094). >>>>>>> >>>>>>> Thanks, >>>>>>> Fraser >>>>>>> >>>>>> >>>>>> bump for review >>>>> >>>>> Patch 0092: ACK >>>>> >>>>> Patch 0093: ACK >>>>> >>>>> Patch 0094: ACK >>>>> >>>>> Patch 0090: >>>>> >>>>> 1) Generic otherNames (san_other) do not work correctly. The OID is not >>>>> included in the value and names with complex type other than KerberosPrincipal >>>>> are not parsed correctly. The value should include the OID and DER blob of the >>>>> name. >>>>> >>>>> 2) With --all, san_other should be included in the result for all otherNames, >>>>> even the known ones, to provide (limited) forward compatibility. >>>>> >>>>> 3) Do we have to support *all* the name types? I mean we could, for the sake >>>>> of completeness, but it might be easier to just keep the few ones we actually >>>>> care about (email, DNS name, principal name, UPN and directory name in your >>>>> patch 0095). >>>> >>>> As far as I remember this reasoning usually comes back to bite us into butt. >>>> >>>> - "Implement only this subset, nobody else needs the other the of ... >>>> (whatever, e.g. DNS record type)." >>>> - "Yes my lord." >>>> >>>> Two months later: >>>> >>>> - "We need to support for XYZ. It was (already) late yesterday!" >>>> >>>> :-) >>> >>> Care to give a concrete example of when this actually happened? Because IIRC >>> this happened once or twice, not "usually". > >I do not have list at hand, sorry. It is just my feeling. > > >>> Anyway, I'm fine with whatever, my point was that additional effort needs to >>> be put in to support "everything" and even then, we wouldn't actually >>> support everything (two months later: "we need to support extension XYZ!"). >>> >> Sure, but in this case it was minimal additional effort to support >> even the esoteric name types - it is only for display after all; if >> an uncommon altname is (somehow) there we can display it. > >That is the main point. The cost is minimal so why not to do it? > maybe because there would not be anyone who would write a test? And feature without tests is bad feature. Petr, are you volunteer? If no then please stop bikeshading. LS From slaznick at redhat.com Tue Aug 16 06:36:31 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 16 Aug 2016 08:36:31 +0200 Subject: [Freeipa-devel] [PATCH 0048] Remove sys.exit() from installer modules In-Reply-To: References: <91e234f8-554f-7efd-a399-d51db521a2fe@redhat.com> <9e9d6098-cbe2-3455-47c0-a21d1aea8ae5@redhat.com> <28420a22-04ad-b04c-4c25-bd9a71f9051f@redhat.com> <9171d38e-da4f-0693-1f53-767dc4dfe219@redhat.com> <5763ABED.9010102@redhat.com> <5763D892.20605@redhat.com> <3b048d9c-03c8-1675-0a3f-20e4b8e293c2@redhat.com> <92bbb69d-cba7-a820-8254-00b684cdbada@redhat.com> Message-ID: <9839e9d7-a967-1702-e226-8e216408d100@redhat.com> On 08/02/2016 01:08 PM, Stanislav Laznicka wrote: > On 07/28/2016 10:57 AM, Martin Basti wrote: >> Hello, >> >> suprisingly, patch needs rebase :) >> >> 1) >> Is the script error the right Exception? > I chose ScriptError because it's able to change the return value of > the script, which is necessary sometimes. RuntimeError, which may seem > more suitable, would not be able to do that. However, I am open for > ideas on which exception type to use. >> >> 2) >> Can you use rather raise Exception(), instead of raise Exception >> > Sure, please see the modified attached patch. >> 3) >> I really hate to print errors to STDOUT from modules and then just >> call exit(1) (duplicated evil), could you replace print('xxx') with >> raise AnException('xxx') > Did that, only kept those prints printing directly to stderr. Not sure > if those should be changed as well. > Bumping for review/opinions. From abokovoy at redhat.com Tue Aug 16 06:59:38 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Aug 2016 09:59:38 +0300 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <14a86320-7801-f00e-98bf-14b46f6a4d81@redhat.com> References: <14a86320-7801-f00e-98bf-14b46f6a4d81@redhat.com> Message-ID: <20160816065938.dec37f3j4x5h2hyp@redhat.com> On Tue, 16 Aug 2016, Stanislav Laznicka wrote: >On 08/12/2016 06:48 PM, Petr Spacek wrote: >>On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>Hello, >>> >>>I updated the design of the Time-Based HBAC Policies according to the >>>discussion we led here earlier. Please check the design page >>>http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest >>>changes are in the Implementation and Feature Management sections. I also >>>added a short How to Use section. >Thank you for the review! I will add some comments inline. >>Nice page! >> >>On the high level it all makes sense. >> >>ad LDAP schema >>============== >>1) Why accessTime attribute is MAY in ipaTimeRule object class? >>Does it make sense to have the object without accessTime? I do not think so. >My idea was that we allow users prepare a few time rule objects before >filling them with the actual times. >>Also, it could be good to add description attribute to the object class and >>incorporate it into commands (including find). >> >Definitely a good idea, I will work that in. >>2) Besides all this, I spent few minutes in dark history of IPA. The >>accessTime attribute was introduced back in 2009 in commit >>"55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for IPAv2". >> >>The commit does not contain any reasoning for the change but I can see that >>the attribute is already used as MAY in old object classes ipaHBACRule and >>ipaSELinuxUserMap. >> >>Is any of these a problem? >I believe that the accessTime attribute was originally brought to IPA >when there was an implementation of time policies for HBAC objects and >it's been rotting there ever since those capabilities were removed. We >may eventually use a new attribute for storage of the time strings as >accessTime by definition is multi-valued which is not what's currently >desired (although we may end up with it some day in the future). >However, I don't think any other use of accessTime should be a problem >as it's been obsoleted for a long time. If the attribute can be used, let's use it. We can limit multiple values in the framework and actively complain about multi-valued accessTime. >>Why is it even in ipaSELinuxUserMap object class? >I'm sorry to say I have no idea. I used it for what it originally was >- a means for storing time strings at HBAC rules. accessTime was part of HBAC rule but when SELinuxUserMap support was added, HBAC lost accessTime functionality --- that's why ipaSELinuxUserMap object class carries accessTime attribute, to specify the time when associated HBAC rule applies. This is one more argument to re-use accessTime attribute. -- / Alexander Bokovoy From pspacek at redhat.com Tue Aug 16 07:41:14 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 16 Aug 2016 09:41:14 +0200 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <20160816000718.GQ23927@dhcp-40-8.bne.redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> <6e5f6d1b-5629-f3b1-fe5d-24593795bf65@redhat.com> <20160815131625.GO23927@dhcp-40-8.bne.redhat.com> <35967055-8dc6-58e2-3c15-2b1187da3435@redhat.com> <20160815135432.GP23927@dhcp-40-8.bne.redhat.com> <0b57369b-57d6-4567-1a4d-ae3c63ba1bbf@redhat.com> <20160816000718.GQ23927@dhcp-40-8.bne.redhat.com> Message-ID: <3c863292-d81c-ca52-24f1-7cd2b8e02fe5@redhat.com> On 16.8.2016 02:07, Fraser Tweedale wrote: > On Mon, Aug 15, 2016 at 03:58:40PM +0200, Petr Spacek wrote: >> On 15.8.2016 15:54, Fraser Tweedale wrote: >>> On Mon, Aug 15, 2016 at 03:31:20PM +0200, Petr Spacek wrote: >>>> On 15.8.2016 15:16, Fraser Tweedale wrote: >>>>> On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote: >>>>>> On 2.8.2016 05:57, Fraser Tweedale wrote: >>>>>>>>> Hah! This is what I get for thinking I know what the output has to look >>>>>>>>> like, and not testing all the way through to requesting the cert. I'll >>>>>>>>> change the profile to generate a subject with CN= instead of UID=. Updated >>>>>>>>> patch is attached. Unfortunately these rules are only updated at >>>>>>>>> ipa-server-install time, so if you'd like to fix it without reinstalling: >>>>>>>>> >>>>>>> (Tangential commentary...) Yeah, currently cert-request demands the >>>>>>> CN. There is a design to relax the requirement to handle empty >>>>>>> subject names (look at SAN only). IMO it would make sense to accept >>>>>>> other "obvious" mappings in Subject DN like accepting UID instead of >>>>>>> CN for user subjects, but that would be a separate RFE. Noone has >>>>>>> actually asked for it yet :) >>>>>> >>>>>> Side-note: >>>>>> I thought that subject format is enforced by certificate profile on server. >>>>>> Am I wrong? >>>>>> >>>>> You are right - what I suggested above would (today) require a >>>>> custom profile. >>>> >>>> Sooo... >>>> can we just relax existing profiles not to require CN= but accept SAN-only CSRs? >>>> >>>> :-) >>>> >>> That is absolutely going to happen as part of >>> http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance :) >> >> Good! >> >> Is it still targeting 4.4.x? >> > It's not going to make it. Ok, I've removed version=4.4.0 tag from http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance -- Petr^2 Spacek From jcholast at redhat.com Tue Aug 16 08:17:07 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 16 Aug 2016 10:17:07 +0200 Subject: [Freeipa-devel] [PATCH] 0004 Added support for authentication with user certificate In-Reply-To: <57383c8e-c4c2-61ad-1045-9e9c20eab4d8@redhat.com> References: <57383c8e-c4c2-61ad-1045-9e9c20eab4d8@redhat.com> Message-ID: <7b5ac93b-e7d8-aa0e-3dd0-21eb7f6ef4e6@redhat.com> On 12.8.2016 15:02, Petr Vobornik wrote: > On 08/12/2016 02:54 PM, Tibor Dudlak wrote: >> Hi, >> >> I have edited my previous patch. >> >> On Thu, Aug 11, 2016 at 11:52 AM, Jan Cholasta > > wrote: >> >> Hi, >> >> On 11.8.2016 09:55, Tibor Dudlak wrote: >> >> Hi, >> >> ... >> >> >> +class login_x509(login_kerberos, KerberosSession, HTTP_Status): >> + key = '/session/login_x509' >> >> login_kerberos already subclasses KerberosSession and HTTP_Status, no need >> to do it again here. In fact, it would be best to split off the bussiness >> logic from login_kerberos into a separate class and inherit both >> login_kerberos and login_x509 from it: >> >> class KerberosLogin(Backend, KerberosSession, HTTP_Status): >> def _on_finalize(self): >> ... >> >> def __call__(self, ...): >> ... >> >> class login_kerberos(KerberosLogin): >> key = '/session/login_kerberos' >> >> class login_x509(KerberosLogin): >> key = '/session/login_x509' >> >> Honza >> >> -- >> Jan Cholasta >> >> >> Thank jcholast for review, it should be all right now. >> >> -- >> Tibor Dudl?k >> Intern - Identity management Special Projects >> Red Hat >> > > Tibor, please reuse the original thread and patch number in each patch > iteration. But append new patch version. E.g. freeipa-ddudla-0003-2-Added... > > Starting new thread for each patch revision makes it hard to track. +1 As far as the patch is concerned, LGTM. -- Jan Cholasta From pvomacka at redhat.com Tue Aug 16 08:43:05 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 16 Aug 2016 10:43:05 +0200 Subject: [Freeipa-devel] [PATCH] 0106, 0107: webui: add warning that only one CA server exists Message-ID: Hello, Please review attached patches which adds warning that only one CA server is installed. https://fedorahosted.org/freeipa/ticket/5828 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0106-Add-warning-about-only-one-existing-CA-server.patch Type: text/x-patch Size: 5986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0107-Set-servers-list-as-default-facet-in-topology-facet-.patch Type: text/x-patch Size: 1232 bytes Desc: not available URL: From ftweedal at redhat.com Tue Aug 16 08:59:28 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 16 Aug 2016 18:59:28 +1000 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <7ad5a28f-9670-b76a-f100-1a6681ac52e5@redhat.com> References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> <885c4c72-6e8a-4220-b25e-f577612368d2@redhat.com> <20160809144716.GA23927@dhcp-40-8.bne.redhat.com> <20160816052401.GR23927@dhcp-40-8.bne.redhat.com> <7ad5a28f-9670-b76a-f100-1a6681ac52e5@redhat.com> Message-ID: <20160816085612.GS23927@dhcp-40-8.bne.redhat.com> On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: > On 16.8.2016 07:24, Fraser Tweedale wrote: > > On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > > > On 9.8.2016 16:47, Fraser Tweedale wrote: > > > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > > > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > > > Please review the attached patch with adds --certificate-out and > > > > > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > > > > > > > > > Note that --certificate-chain-out currently writes a bogus file due > > > > > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > > > > > 1) The client-side *-out options should be defined on the client side, not > > > > > > > on the server side. > > > > > > > > > > > > > Will option defined on client side be propagated to, and observable > > > > > > in the ipaserver plugin? The ipaserver plugin needs to observe that > > > > > > *-out has been requested and executes additional command(s) on that > > > > > > basis. > > > > > > > > > > Is there a reason not to *always* return the certs? > > > > > > > > > We hit Dogtag to retrieve them. > > > > > > I don't think that's an issue in a -show command. > > > > > cert_show is invoked by other commands (cert_find*, cert_show, > > cert_request, cert_status, ca_del) but these all hit Dogtag anyway > > so I suppose that's fine. I'll return the cert *and* the chain in > > separate attributes, unconditionally. > > > > > > > > > > > > > > > > > > > > > > > > > > 2) I don't think there should be additional information included in summary > > > > > > > (and it definitely should not be multi-line). I would rather inform the user > > > > > > > via an error message when unable to write the files. > > > > > > > > > > > > > I was just following the pattern of other commands that write certs, > > > > > > profile config, etc. Apart from consistency with other commands I > > > > > > agree that there is no need to have it. So I will remove it. > > > > > > > > > > > > > If you think there is an actual value in informing the user about > > > > > > > successfully writing the files, please use ipalib.messages for the job. > > > > > > > > > > > > > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 would be > > > > > > > concatenated PEM, as that's the most commonly used format in IPA (in > > > > > > > installers, there are no cert chains in API commands ATM). > > > > > > > > > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > > > > > or concatenated PEMs, but sometimes they must be concatenated > > > > > > forward, and othertimes backwards. There is no one size fits all. > > > > > > > > > > True, which is exactly why I think we should at least be self-consistent and > > > > > use concatenated PEM (and multi-value DER over the wire). > > > > > > > > > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept > > > > header). > > > > > > > > If we want list-of-PEMs between server and client we have to convert > > > > on the server. Do we have a good way of doing this without exec'ing > > > > `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' > > > > to do the conversion on the server? python-nss does not have PKCS7 > > > > functions and I am not keen on adding a pyasn1 PKCS7 parser just for > > > > the sake of pushing bits as list-of-PEMs. > > > > > > I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other. > > > For example, if we added a call to retrieve external CA chain using certs > > > from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to > > > PKCS#7 if it was our cert chain format of choice. > > > > > > What we can avoid though is executing "openssl pkcs7" to do the conversion - > > > we can use an approach similar to our DNSSEC code and use python-cffi to > > > call libcrypto's PKCS#7 conversion routines instead. > > > > > I had a look at the OpenSSL API for parsing PKCS #7; now I prefer to > > exec `openssl' to do the job :) > > > > I will transmit DER-encoded PKCS #7 object on the wire; we cannot > > used multi-valued DER attribute because order is important. Client > > will convert to PEMs. > > Well, my point was not to send PKCS#7 over the wire, so that clients > (including 3rd party clients) do not have to convert from PKCS#7 themselves. > > In fact we can use multi-valued DER - whatever you send over the wire from > the server will be received in the exact same order by the client. Even if > it wasn't, you can easily restore the order by matching issuer and subject > names of the certificates. > Oh yeah - I forgot it is not a real LDAP attribute :S OK, conversion on server. > > > > Should have new patch on list this afternoon. > > > > Thanks, > > Fraser > > > > > > > > > > FWIW, man pages and code suggest that PKCS #7 is accepted in > > > > installer, etc. > > > > > > True, but that's a relatively new feature (since 4.1) and the installer > > > internally executes "openssl pkcs7" to convert PKCS #7 to list of certs :-) > > > > > > > > > > > > > We can add an option to control the format later, but for now, > > > > > > Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst > > > > > > case is an admin has to invoke `openssl pkcs7' and concat the certs > > > > > > themselves. > > > > > > > > > > AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, > > > > > so I'm afraid the worst case would happen virtually always. > > > > > > > > > If you're OK with invoking OpenSSL on the client to convert PKCS #7 > > > > to list-of-PEMs (similar to what is done in > > > > ipapython.certdb.NSSDatabase) then we can have the client perform > > > > the conversion. > > > > > > See above. > > > > > > > > > > > > > > > > > > > > > > > > > > > 4) Over the wire, the certs should be DER-formatted, as that's the most > > > > > > > common wire format in other API commands. > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > > > > > 5) What is the benefit in having the CA cert and the rest of the chain > > > > > > > separate? For end-entity certs it makes sense to separate the cert from the > > > > > > > CA chain, but for CA certs, you usually want the full chain, no? > > > > > > > > > > > > > If you want to anchor trust directly at a subca (e.g. restrict VPN > > > > > > login to certs issued by VPN sub-CA) then you often just want the > > > > > > cert. The chain option does subsume it, at cost of more work for > > > > > > administrators with this use case. I think it makes sense to keep > > > > > > both options. > > > > > > > > > > Does it? From what you described above, you either want just the sub-CA > > > > > cert, or the full chain including the sub-CA cert, in which case it might > > > > > make more sense to have a single --out option and a --chain flag. > > > > > > > > > How about --certificate-out which defaults to single cert, but does > > > > chain (as list-of-PEMs) when --chain flag given. > > > > > > > > Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more > > > > `--out' options. > > > > > > +1 > > > > > > > > > > > Thanks, > > > > Fraser > > > > > > > > > > > > > -- > > > Jan Cholasta > > > -- > Jan Cholasta From mbasti at redhat.com Tue Aug 16 10:04:39 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 12:04:39 +0200 Subject: [Freeipa-devel] [PATCH 0033][Tests] Fix test_ipalib/test_output failing due to change of Output class behaviour In-Reply-To: <6e6d97ff-ab33-f5c6-9a54-f31aa3f44571@redhat.com> References: <6e6d97ff-ab33-f5c6-9a54-f31aa3f44571@redhat.com> Message-ID: <907e0b51-1b2a-3818-ac17-d7943b5600bf@redhat.com> On 15.08.2016 14:27, Lenka Doudova wrote: > Hi, > > attaching patch for https://fedorahosted.org/freeipa/ticket/6189 > > > Lenka > > > ACK master: f75735b16af5e7a92929d54076b773dadb8c81bc Tests: test_ipalib/test_output fails due to change of Output behaviour -------------- next part -------------- An HTML attachment was scrubbed... URL: From slaznick at redhat.com Tue Aug 16 10:06:04 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 16 Aug 2016 12:06:04 +0200 Subject: [Freeipa-devel] [PATCH 0048] Remove sys.exit() from installer modules In-Reply-To: <9839e9d7-a967-1702-e226-8e216408d100@redhat.com> References: <91e234f8-554f-7efd-a399-d51db521a2fe@redhat.com> <9e9d6098-cbe2-3455-47c0-a21d1aea8ae5@redhat.com> <28420a22-04ad-b04c-4c25-bd9a71f9051f@redhat.com> <9171d38e-da4f-0693-1f53-767dc4dfe219@redhat.com> <5763ABED.9010102@redhat.com> <5763D892.20605@redhat.com> <3b048d9c-03c8-1675-0a3f-20e4b8e293c2@redhat.com> <92bbb69d-cba7-a820-8254-00b684cdbada@redhat.com> <9839e9d7-a967-1702-e226-8e216408d100@redhat.com> Message-ID: <4bc9d3ca-5081-8a0f-e813-57cf3d87371d@redhat.com> On 08/16/2016 08:36 AM, Stanislav Laznicka wrote: > On 08/02/2016 01:08 PM, Stanislav Laznicka wrote: >> On 07/28/2016 10:57 AM, Martin Basti wrote: >>> Hello, >>> >>> suprisingly, patch needs rebase :) >>> >>> 1) >>> Is the script error the right Exception? >> I chose ScriptError because it's able to change the return value of >> the script, which is necessary sometimes. RuntimeError, which may >> seem more suitable, would not be able to do that. However, I am open >> for ideas on which exception type to use. >>> >>> 2) >>> Can you use rather raise Exception(), instead of raise Exception >>> >> Sure, please see the modified attached patch. >>> 3) >>> I really hate to print errors to STDOUT from modules and then just >>> call exit(1) (duplicated evil), could you replace print('xxx') with >>> raise AnException('xxx') >> Did that, only kept those prints printing directly to stderr. Not >> sure if those should be changed as well. >> > Bumping for review/opinions. > Also a self-NACK, there were some sys imports that should not have been there anymore (thanks, mbasti). Attaching a fixed version. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0048-4-Remove-sys.exit-from-install-modules-and-scripts.patch Type: text/x-patch Size: 43791 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 16 10:05:23 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 12:05:23 +0200 Subject: [Freeipa-devel] [PATCH 0031, 0032][Tests] Fixes for failing test_ipalib/test_messages tests In-Reply-To: <08beb447-3dc1-3fd5-3191-37a10320ba58@redhat.com> References: <08beb447-3dc1-3fd5-3191-37a10320ba58@redhat.com> Message-ID: On 15.08.2016 11:35, Lenka Doudova wrote: > Hi, > > attached are patches that are fixing 3 failing tests in > test_ipalib/test_messages.py. > > > Lenka > > > ACK pushed to master 425291dc19fb47c9f7a957b1af8da4c1341092fc Fix malformed or missing docstrings in ipalib/messages 71d0bc7c106c5db34ff193f19df429ba9d2373a9 Tests: Add data attribute to messages -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 16 10:14:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 12:14:45 +0200 Subject: [Freeipa-devel] [patch 0052] ipatests: Fix wrong fixture in kerberos principal alias test In-Reply-To: <4fbd1a0b-31c9-396d-0af2-1f98a2638109@redhat.com> References: <4fbd1a0b-31c9-396d-0af2-1f98a2638109@redhat.com> Message-ID: On 15.08.2016 14:35, Milan Kub?k wrote: > Fixes issue in ticket https://fedorahosted.org/freeipa/ticket/6197 > > > > ACK Pushed to master: b92b1d7d7f34cfc45f218d56160d2e502648cf51 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 16 10:17:41 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 12:17:41 +0200 Subject: [Freeipa-devel] [PATCH] 0001: Silence sshd messages during install In-Reply-To: References: <3fe0b9ae-9b22-3a9a-3d4a-067c51a22452@redhat.com> <19dd378c-cc99-90f5-411c-7f472b87775f@redhat.com> <20160808115831.s7eylgmmdrg5sift@redhat.com> <40c23042-0d7b-c9a8-6c3a-124363897fe3@redhat.com> <301eae1a-6c7b-010d-2716-cca4e4688d47@redhat.com> Message-ID: On 11.08.2016 15:45, Martin Basti wrote: > > > On 11.08.2016 15:40, Jan Cholasta wrote: >> On 8.8.2016 14:25, Martin Basti wrote: >>> >>> >>> On 08.08.2016 13:58, Alexander Bokovoy wrote: >>>> On Mon, 08 Aug 2016, Jan Cholasta wrote: >>>>> On 19.7.2016 08:40, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 9.7.2016 14:46, Ben Lipton wrote: >>>>>>> On 07/07/2016 11:19 AM, Ben Lipton wrote: >>>>>>>> >>>>>>>> Thanks for the review! Comments below. >>>>>>>> >>>>>>>> >>>>>>>> On 07/01/2016 07:42 AM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 29.06.2016 20:46, Ben Lipton wrote: >>>>>>>>>> The attached patch silences some annoying messages I've been >>>>>>>>>> getting >>>>>>>>>> when upgrading the freeipa-client package on F24: >>>>>>>>>> """ >>>>>>>>>> WARNING: 'UseLogin yes' is not supported in Fedora and may cause >>>>>>>>>> several problems. >>>>>>>> This will be fixed by openssh-7.2p2-9.fc24 >>>>>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=1350347) so we >>>>>>>> probably >>>>>>>> shouldn't worry about it. >>>>>>>>>> Could not load host key: /etc/ssh/ssh_host_dsa_key >>>>>>>> This is because by default sshd looks for all of >>>>>>>> /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, >>>>>>>> /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key, but >>>>>>>> Fedora doesn't generate a DSA key by default. >>>>>>>>>> """ >>>>>>>>>> >>>>>>>>>> Since the script causing the message only looks at the return >>>>>>>>>> code >>>>>>>>>> from sshd to determine the right options to use, I thought it >>>>>>>>>> might >>>>>>>>>> be ok to discard the output. What do you think? >>>>>>>>>> >>>>>>>>>> Ben >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hello, I don't like to hiding errors/warnings. Can you >>>>>>>>> determine and >>>>>>>>> solve the root cause? >>>>>>>> >>>>>>>> I definitely agree with this in principle, but in this case the >>>>>>>> purpose of this code is to try different, potentially wrong, >>>>>>>> parameters to sshd until it finds a combination that it >>>>>>>> accepts. It >>>>>>>> seems like in some environments this would produce error messages >>>>>>>> that >>>>>>>> aren't actionable and don't indicate any problem for package >>>>>>>> function, >>>>>>>> which is why I didn't think these messages were necessarily worth >>>>>>>> preserving. >>>>>>>> >>>>>>>> On the other hand, if the code makes the wrong decision about sshd >>>>>>>> version we might be interested in error logs that show why. Can we >>>>>>>> log >>>>>>>> this to a file instead of the console, maybe? >>>>>>>> >>>>>>>> If you'd prefer just addressing the root cause, a patch that >>>>>>>> prevents >>>>>>>> the missing host key error is attached, but it won't stop the >>>>>>>> error >>>>>>>> messages showing up when openssh is an older version. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ben >>>>>>>> >>>>>>>> >>>>>>> Whoops, realized that my patch created a tempfile and didn't delete >>>>>>> it. >>>>>>> Updated. >>>>>> >>>>>> I think the first version of the patch was OK. sshd is called >>>>>> only to >>>>>> check which set of authorized keys options to use, we don't >>>>>> really care >>>>>> about anything else, so we can safely ignore whatever it puts to >>>>>> stderr. >>>>> >>>>> Bump. >>>>> >>>>> ACK on the first version of the patch >>>>> (freeipa-blipton-0001-Silence-sshd-messages-during-install.patch). >>>>> >>>>> Anyone against pushing it? >>>> Given that newer OpenSSH version will silence it anyway, I'm OK >>>> with the >>>> interim fix. >>> Pushed to master: c15ba1f9e8c7d236586d46271fce7c3950b509da >> >> You pushed the wrong patch (0002). >> > > Yes, sorry, I forgot how to numbers > > Fixed patch attached. > > fix (revert + original patch) pushed to master: 58d28b741022d06d7050db66997fd5d527b99bc1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 16 10:34:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 12:34:45 +0200 Subject: [Freeipa-devel] [PATCHES] Coverity fixes In-Reply-To: <1471165196.3492.10.camel@redhat.com> References: <1469440019.18067.66.camel@redhat.com> <6dcfcd32-05e3-d36c-484a-bb074373af4c@redhat.com> <20160805121337.GG6891@10.4.128.1> <1ce4148c-8b9e-88c9-e612-6b64a0f697f6@redhat.com> <1471165196.3492.10.camel@redhat.com> Message-ID: On 14.08.2016 10:59, Simo Sorce wrote: > On Thu, 2016-08-11 at 14:51 +0200, Martin Basti wrote: >> On 05.08.2016 14:13, Lukas Slebodnik wrote: >>> On (05/08/16 12:43), Petr Vobornik wrote: >>>> On 07/28/2016 01:01 PM, Martin Basti wrote: >>>>> On 25.07.2016 11:46, Simo Sorce wrote: >>>>>> The attached patches fix some minor issues found by coverity, and pull >>>>>> in other fixes released by the asn1c project. >>>>>> >>>>>> Simo. >>>>>> >>>>>> >>>>>> >>>>> I cannot build RPMS with this patch, is there any missing build dependency? >>>>> >>>>> /bin/sh ./libtool --tag=CC --mode=link gcc -Wall -Wshadow >>>>> -Wstrict-prototypes -Wpointer-arith -Wcast-align >>>>> -Werror-implicit-function-declaration -O2 -g -pipe -Wall >>>>> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>>>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >>>>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall >>>>> -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare >>>>> -Wno-missing-field-initializers -Wl,-z,relro >>>>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o >>>>> ipa-client-common.o ipa_krb5.o ../asn1/libipaasn1.la -lkrb5 -lk5crypto -lcom_err >>>>> -llber -lldap -lsasl2 -lpopt -lini_config -lbasicobjects -lref_array >>>>> -lcollection -lini_config -lini_config >>>>> libtool: link: gcc -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith >>>>> -Wcast-align -Werror-implicit-function-declaration -O2 -g -pipe -Wall >>>>> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>>>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >>>>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall >>>>> -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare >>>>> -Wno-missing-field-initializers -Wl,-z -Wl,relro >>>>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o >>>>> ipa-client-common.o ipa_krb5.o ../asn1/.libs/libipaasn1.a -lkrb5 -lk5crypto >>>>> -lcom_err -llber -lldap -lsasl2 -lpopt -lbasicobjects -lref_array -lcollection >>>>> -lini_config >>>>> ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_decode_uper': >>>>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:897: >>>>> undefined reference to `uper_open_type_get' >>>>> ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_encode_uper': >>>>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:982: >>>>> undefined reference to `uper_open_type_put' >>>>> ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function >>>>> `SEQUENCE_handle_extensions': >>>>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1285: >>>>> undefined reference to `uper_open_type_put' >>>>> ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function `SEQUENCE_decode_uper': >>>>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1187: >>>>> undefined reference to `uper_open_type_get' >>>>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1203: >>>>> undefined reference to `uper_open_type_skip' >>>>> collect2: error: ld returned 1 exit status >>>>> >>>>> Martin^2 >>>>> >>>> Bumping. Was it temporary issue or issue in the patch? >>>> >>> I could not see such error. >>> However, these patches would be good to test with coverity. >>> We need to use fedora rawhide for testing due to BuildRequires >>> in freeipa.spec. But C-part of freeIPA cannot be compiled on rawhide >>> due to new samba (4.5). Patches are already on the list. >>> >>> LS >>> >> Lukas helped me to fix error I reported before (missing entries in >> Makefile.am), so I run covscan and I get bunch of new errors. >> >> Question is, do we want push autogenerated code? > Yes we definitely want it pushed, so covscan can look at it and we can > commit fixes before the upstream project (which is very slow) takes them > in. > > Once these errors crop up in our covscan report I will take another pass > at fixing the real ones and ignoring false positives. > > Simo. > >> Error: FORWARD_NULL (CWE-476): [#def1] >> freeipa-4.4.0/asn1/asn1c/INTEGER.c:463: assign_zero: Assigning: >> "dec_value_start" = "NULL". >> freeipa-4.4.0/asn1/asn1c/INTEGER.c:488: var_deref_model: Passing null >> pointer "dec_value_start" to "asn_strtol_lim", which dereferences it. >> freeipa-4.4.0/asn1/asn1c/INTEGER.c:975:2: deref_parm: Directly >> dereferencing parameter "str". >> # 973| if(str >= *end) return ASN_STRTOL_ERROR_INVAL; >> # 974| >> # 975|-> switch(*str) { >> # 976| case '-': >> # 977| last_digit_max++; >> >> Error: MISSING_BREAK (CWE-484): [#def2] >> freeipa-4.4.0/asn1/asn1c/INTEGER.c:976: unterminated_case: The case for >> value "'-'" is not terminated by a 'break' statement. >> freeipa-4.4.0/asn1/asn1c/INTEGER.c:979: fallthrough: The above case >> falls through to this one. >> # 977| last_digit_max++; >> # 978| sign = -1; >> # 979|-> case '+': >> # 980| str++; >> # 981| if(str >= *end) { >> >> Error: NEGATIVE_RETURNS (CWE-394): [#def3] >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:381: var_tested_neg: Variable >> "tlv_len" tests negative. >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:391: var_assign: Assigning: >> signed variable "sel->left" = "tlv_len". >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:247: var_assign: Assigning: >> unsigned variable "Left" = "sel->left". >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:275: negative_returns: "Left" is >> passed to a parameter that cannot be negative. >> freeipa-4.4.0/asn1/asn1c/ber_tlv_tag.c:33:2: parm_loop_bound: Using >> unsigned parameter "size" in a loop exit test. >> # 273| } >> # 274| >> # 275|-> tl = ber_fetch_tag(buf_ptr, Left, &tlv_tag); >> # 276| ASN_DEBUG("fetch tag(size=%ld,L=%ld), %sstack, >> left=%ld, wn=%ld, tl=%ld", >> # 277| (long)size, (long)Left, sel?"":"!", >> >> Error: FORWARD_NULL (CWE-476): [#def4] >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:583: var_compare_op: Comparing >> "st->buf" to null implies that "st->buf" might be null. >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:591: alias_transfer: Assigning: >> "buf" = "st->buf". >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:601: var_deref_op: Dereferencing >> null pointer "buf". >> # 599| p = scratch; >> # 600| } >> # 601|-> *p++ = h2c[(*buf >> 4) & 0x0F]; >> # 602| *p++ = h2c[*buf & 0x0F]; >> # 603| } >> >> Error: FORWARD_NULL (CWE-476): [#def5] >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:583: var_compare_op: Comparing >> "st->buf" to null implies that "st->buf" might be null. >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:591: alias_transfer: Assigning: >> "buf" = "st->buf". >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:615: var_deref_op: Dereferencing >> null pointer "buf". >> # 613| _i_ASN_TEXT_INDENT(1, ilevel); >> # 614| } >> # 615|-> *p++ = h2c[(*buf >> 4) & 0x0F]; >> # 616| *p++ = h2c[*buf & 0x0F]; >> # 617| *p++ = 0x20; >> >> Error: FORWARD_NULL (CWE-476): [#def6] >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:739: var_compare_op: Comparing >> "st->buf" to null implies that "st->buf" might be null. >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:742: alias_transfer: Assigning: >> "buf" = "st->buf". >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:745: var_deref_op: Dereferencing >> null pointer "buf". >> # 743| end = buf + st->size; >> # 744| for(ss = buf; buf < end; buf++) { >> # 745|-> unsigned int ch = *buf; >> # 746| int s_len; /* Special encoding sequence length */ >> # 747| >> >> Error: FORWARD_NULL (CWE-476): [#def7] >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1659: var_compare_op: Comparing >> "st->buf" to null implies that "st->buf" might be null. >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1665: alias_transfer: Assigning: >> "buf" = "st->buf". >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1674: var_deref_op: >> Dereferencing null pointer "buf". >> # 1672| p = scratch; >> # 1673| } >> # 1674|-> *p++ = h2c[(*buf >> 4) & 0x0F]; >> # 1675| *p++ = h2c[*buf & 0x0F]; >> # 1676| *p++ = 0x20; >> >> Error: REVERSE_INULL (CWE-476): [#def8] >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1706: deref_ptr: Directly >> dereferencing pointer "td". >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1713: check_after_deref: >> Null-checking "td" suggests that it may be null, but it has already been >> dereferenced on all paths leading to the check. >> # 1711| struct _stack *stck; >> # 1712| >> # 1713|-> if(!td || !st) >> # 1714| return; >> # 1715| >> >> Error: DEADCODE (CWE-561): [#def9] >> freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:40: assignment: Assigning: >> "len" = "0L". >> freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:44: cond_at_least: Condition >> "len < 0L", taking false branch. Now the value of "len" is at least 0. >> freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:54: assignment: Assigning: >> "lenplusepsilon" = "(size_t)len + 1024UL". >> freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:63: at_least: At condition >> "lenplusepsilon < 0L", the value of "lenplusepsilon" must be at least 1024. >> freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:63: dead_error_condition: The >> condition "lenplusepsilon < 0L" cannot be true. >> freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:65: dead_error_line: Execution >> cannot reach this statement: "return -1L;". >> # 63| if(lenplusepsilon < 0) { >> # 64| /* Too large length value */ >> # 65|-> return -1; >> # 66| } >> # 67| >> >> Error: REVERSE_INULL (CWE-476): [#def10] >> freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:1034: deref_ptr: Directly >> dereferencing pointer "td". >> freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:1037: check_after_deref: >> Null-checking "td" suggests that it may be null, but it has already been >> dereferenced on all paths leading to the check. >> # 1035| int present; >> # 1036| >> # 1037|-> if(!td || !ptr) >> # 1038| return; >> # 1039| >> >> Error: RESOURCE_LEAK (CWE-772): [#def11] >> freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1147: alloc_fn: Storage is >> returned from allocation function "malloc". >> freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1147: var_assign: Assigning: >> "epres" = storage returned from "malloc(bmlength + 15L >> 3)". >> freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1151: noescape: Resource >> "epres" is not freed or pointed-to in "per_get_many_bits". >> freeipa-4.4.0/asn1/asn1c/per_support.c:123:48: noescape: >> "per_get_many_bits(asn_per_data_t *, uint8_t *, int, int)" does not free >> or save its parameter "dst". >> freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1152: leaked_storage: >> Variable "epres" going out of scope leaks the storage it points to. >> # 1150| /* Get the extensions map */ >> # 1151| if(per_get_many_bits(pd, epres, 0, bmlength)) >> # 1152|-> _ASN_DECODE_STARVED; >> # 1153| >> # 1154| memset(&epmd, 0, sizeof(epmd)); >> >> Error: CHECKED_RETURN (CWE-252): [#def12] >> freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1320: check_return: Calling >> "per_put_few_bits" without checking return value (as is done elsewhere >> 23 out of 28 times). >> freeipa-4.4.0/asn1/asn1c/INTEGER.c:724: example_checked: Example 1: >> "per_put_few_bits(po, inext, 1)" has its value checked in >> "per_put_few_bits(po, inext, 1)". >> freeipa-4.4.0/asn1/asn1c/NativeEnumerated.c:180: example_checked: >> Example 2: "per_put_few_bits(po, inext, 1)" has its value checked in >> "per_put_few_bits(po, inext, 1)". >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1307: example_checked: Example >> 3: "per_put_few_bits(po, ch, unit_bits)" has its value checked in >> "per_put_few_bits(po, ch, unit_bits)". >> freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:949: example_checked: Example >> 4: "per_put_few_bits(po, 1U, 1)" has its value checked in >> "per_put_few_bits(po, 1U, 1)". >> freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1282: example_checked: >> Example 5: "per_put_few_bits(po1, present, 1)" has its value checked in >> "per_put_few_bits(po1, present, 1)". >> # 1318| if(specs->ext_before >= 0) { >> # 1319| n_extensions = SEQUENCE_handle_extensions(td, sptr, 0, 0); >> # 1320|-> per_put_few_bits(po, n_extensions ? 1 : 0, 1); >> # 1321| } else { >> # 1322| n_extensions = 0; /* There are no extensions to >> encode */ >> >> Error: DEADCODE (CWE-561): [#def13] >> freeipa-4.4.0/asn1/asn1c/per_encoder.c:126: cond_notnull: Condition >> "td", taking true branch. Now the value of "td" is not "NULL". >> freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: notnull: At condition "td", >> the value of "td" cannot be "NULL". >> freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: dead_error_condition: The >> condition "td" must be true. >> freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: dead_error_line: Execution >> cannot reach the expression """" inside this statement: >> "ASN_DEBUG("Failed to encode...". >> # 144| >> # 145| if(_uper_encode_flush_outp(&po)) >> # 146|-> _ASN_ENCODE_FAILED; >> # 147| } >> # 148| >> >> Error: DEADCODE (CWE-561): [#def14] >> freeipa-4.4.0/asn1/asn1c/per_opentype.c:176: assignment: Assigning: >> "padding" = "pd->moved % 8UL". >> freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: between: At condition >> "padding > 7L", the value of "padding" must be between 1 and 7. >> freeipa-4.4.0/asn1/asn1c/per_opentype.c:177: cond_cannot_single: >> Condition "padding", taking true branch. Now the value of "padding" >> cannot be equal to 0. >> freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: cannot_single: At condition >> "padding > 7L", the value of "padding" cannot be equal to 0. >> freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: dead_error_condition: The >> condition "padding > 7L" cannot be true. >> freeipa-4.4.0/asn1/asn1c/per_opentype.c:180: dead_error_begin: Execution >> cannot reach this statement: "ASN_DEBUG("Too large paddin...". >> # 178| int32_t pvalue; >> # 179| if(padding > 7) { >> # 180|-> ASN_DEBUG("Too large padding %d in open type", >> # 181| (int)padding); >> # 182| rv.code = RC_FAIL; >> >> Error: OVERRUN (CWE-119): [#def15] >> freeipa-4.4.0/asn1/asn1c/per_support.c:14: assignment: Assigning: "n" = >> "(n + 1) % 2". The value of "n" is now between 0 and 1 (inclusive). >> freeipa-4.4.0/asn1/asn1c/per_support.c:15: overrun-buffer-arg: Calling >> "snprintf" with "buf[n]" and "64UL" is suspicious because the function >> call may access "buf" at byte "n * sizeof (char [32]) + 63UL". [Note: >> The source code implementation of the function has been overridden by a >> builtin model.] >> # 13| static int n; >> # 14| n = (n+1) % 2; >> # 15|-> snprintf(buf[n], sizeof(buf), >> # 16| "{m=%ld span %+ld[%d..%d] (%d)}", >> # 17| (long)pd->moved, >> >> Error: FORWARD_NULL (CWE-476): [#def16] >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1513: var_compare_op: Comparing >> "st->buf" to null implies that "st->buf" might be null. >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1618: alias_transfer: Assigning: >> "buf" = "st->buf". >> freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1631: var_deref_model: Passing >> null pointer "buf" to "per_put_many_bits", which dereferences it. >> freeipa-4.4.0/asn1/asn1c/per_support.c:419:4: deref_parm: Directly >> dereferencing parameter "src". >> # 417| >> # 418| if(nbits >= 24) { >> # 419|-> value = (src[0] << 16) | (src[1] << 8) | src[2]; >> # 420| src += 3; >> # 421| nbits -= 24; > I put missing files to makefile before push ACK master: * 512aa90bec108a1d523ac5868342c68892f2c4cb Regenerate asn1 code * cf0816f41503c9a556373b37b987dcb7a9be040b Additional coverity fixes. From simo at redhat.com Tue Aug 16 10:38:43 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Aug 2016 06:38:43 -0400 Subject: [Freeipa-devel] [PATCHES] Coverity fixes In-Reply-To: References: <1469440019.18067.66.camel@redhat.com> <6dcfcd32-05e3-d36c-484a-bb074373af4c@redhat.com> <20160805121337.GG6891@10.4.128.1> <1ce4148c-8b9e-88c9-e612-6b64a0f697f6@redhat.com> <1471165196.3492.10.camel@redhat.com> Message-ID: <1471343923.5114.5.camel@redhat.com> On Tue, 2016-08-16 at 12:34 +0200, Martin Basti wrote: > > On 14.08.2016 10:59, Simo Sorce wrote: > > > > On Thu, 2016-08-11 at 14:51 +0200, Martin Basti wrote: > > > > > > On 05.08.2016 14:13, Lukas Slebodnik wrote: > > > > > > > > On (05/08/16 12:43), Petr Vobornik wrote: > > > > > > > > > > On 07/28/2016 01:01 PM, Martin Basti wrote: > > > > > > > > > > > > On 25.07.2016 11:46, Simo Sorce wrote: > > > > > > > > > > > > > > The attached patches fix some minor issues found by > > > > > > > coverity, and pull > > > > > > > in other fixes released by the asn1c project. > > > > > > > > > > > > > > Simo. > > > > > > > > > > > > > > > > > > > > > > > > > > > I cannot build RPMS with this patch, is there any missing > > > > > > build dependency? > > > > > > > > > > > > /bin/sh ./libtool??--tag=CC???--mode=link gcc??-Wall > > > > > > -Wshadow > > > > > > -Wstrict-prototypes -Wpointer-arith -Wcast-align > > > > > > -Werror-implicit-function-declaration??-O2 -g -pipe -Wall > > > > > > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 > > > > > > -fexceptions > > > > > > -fstack-protector-strong --param=ssp-buffer-size=4 > > > > > > -grecord-gcc-switches > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 > > > > > > -mtune=generic -g -O2 -Wall > > > > > > -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign- > > > > > > compare > > > > > > -Wno-missing-field-initializers???-Wl,-z,relro > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld??-o ipa- > > > > > > getkeytab ipa-getkeytab.o > > > > > > ipa-client-common.o ipa_krb5.o ../asn1/libipaasn1.la -lkrb5 > > > > > > -lk5crypto -lcom_err > > > > > > -llber -lldap -lsasl2 -lpopt??-lini_config -lbasicobjects > > > > > > -lref_array > > > > > > -lcollection??-lini_config -lini_config > > > > > > libtool: link: gcc -Wall -Wshadow -Wstrict-prototypes > > > > > > -Wpointer-arith > > > > > > -Wcast-align -Werror-implicit-function-declaration -O2 -g > > > > > > -pipe -Wall > > > > > > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 > > > > > > -fexceptions > > > > > > -fstack-protector-strong --param=ssp-buffer-size=4 > > > > > > -grecord-gcc-switches > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 > > > > > > -mtune=generic -g -O2 -Wall > > > > > > -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign- > > > > > > compare > > > > > > -Wno-missing-field-initializers -Wl,-z -Wl,relro > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa- > > > > > > getkeytab ipa-getkeytab.o > > > > > > ipa-client-common.o ipa_krb5.o ../asn1/.libs/libipaasn1.a > > > > > > -lkrb5 -lk5crypto > > > > > > -lcom_err -llber -lldap -lsasl2 -lpopt -lbasicobjects > > > > > > -lref_array -lcollection > > > > > > -lini_config > > > > > > ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function > > > > > > `CHOICE_decode_uper': > > > > > > /root/freeipa/rpmbuild/BUILD/freeipa- > > > > > > 4.4.0/asn1/asn1c/constr_CHOICE.c:897: > > > > > > undefined reference to `uper_open_type_get' > > > > > > ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function > > > > > > `CHOICE_encode_uper': > > > > > > /root/freeipa/rpmbuild/BUILD/freeipa- > > > > > > 4.4.0/asn1/asn1c/constr_CHOICE.c:982: > > > > > > undefined reference to `uper_open_type_put' > > > > > > ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function > > > > > > `SEQUENCE_handle_extensions': > > > > > > /root/freeipa/rpmbuild/BUILD/freeipa- > > > > > > 4.4.0/asn1/asn1c/constr_SEQUENCE.c:1285: > > > > > > undefined reference to `uper_open_type_put' > > > > > > ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function > > > > > > `SEQUENCE_decode_uper': > > > > > > /root/freeipa/rpmbuild/BUILD/freeipa- > > > > > > 4.4.0/asn1/asn1c/constr_SEQUENCE.c:1187: > > > > > > undefined reference to `uper_open_type_get' > > > > > > /root/freeipa/rpmbuild/BUILD/freeipa- > > > > > > 4.4.0/asn1/asn1c/constr_SEQUENCE.c:1203: > > > > > > undefined reference to `uper_open_type_skip' > > > > > > collect2: error: ld returned 1 exit status > > > > > > > > > > > > Martin^2 > > > > > > > > > > > Bumping. Was it temporary issue or issue in the patch? > > > > > > > > > I could not see such error. > > > > However, these patches would be good to test with coverity. > > > > We need to use fedora rawhide for testing due to BuildRequires > > > > in freeipa.spec. But C-part of freeIPA cannot be compiled on > > > > rawhide > > > > due to new samba (4.5). Patches are already on the list. > > > > > > > > LS > > > > > > > Lukas helped me to fix error I reported before (missing entries > > > in > > > Makefile.am), so I run covscan and I get bunch of new errors. > > > > > > Question is, do we want push autogenerated code? > > Yes we definitely want it pushed, so covscan can look at it and we > > can > > commit fixes before the upstream project (which is very slow) takes > > them > > in. > > > > Once these errors crop up in our covscan report I will take another > > pass > > at fixing the real ones and ignoring false positives. > > > > Simo. > > > > > > > > Error: FORWARD_NULL (CWE-476): [#def1] > > > freeipa-4.4.0/asn1/asn1c/INTEGER.c:463: assign_zero: Assigning: > > > "dec_value_start" = "NULL". > > > freeipa-4.4.0/asn1/asn1c/INTEGER.c:488: var_deref_model: Passing > > > null > > > pointer "dec_value_start" to "asn_strtol_lim", which dereferences > > > it. > > > freeipa-4.4.0/asn1/asn1c/INTEGER.c:975:2: deref_parm: Directly > > > dereferencing parameter "str". > > > #??973|???????if(str >= *end) return ASN_STRTOL_ERROR_INVAL; > > > #??974| > > > #??975|->?????switch(*str) { > > > #??976|???????case '-': > > > #??977|???????????last_digit_max++; > > > > > > Error: MISSING_BREAK (CWE-484): [#def2] > > > freeipa-4.4.0/asn1/asn1c/INTEGER.c:976: unterminated_case: The > > > case for > > > value "'-'" is not terminated by a 'break' statement. > > > freeipa-4.4.0/asn1/asn1c/INTEGER.c:979: fallthrough: The above > > > case > > > falls through to this one. > > > #??977|???????????last_digit_max++; > > > #??978|???????????sign = -1; > > > #??979|->?????case '+': > > > #??980|???????????str++; > > > #??981|???????????if(str >= *end) { > > > > > > Error: NEGATIVE_RETURNS (CWE-394): [#def3] > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:381: var_tested_neg: > > > Variable > > > "tlv_len" tests negative. > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:391: var_assign: > > > Assigning: > > > signed variable "sel->left" = "tlv_len". > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:247: var_assign: > > > Assigning: > > > unsigned variable "Left" = "sel->left". > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:275: negative_returns: > > > "Left" is > > > passed to a parameter that cannot be negative. > > > freeipa-4.4.0/asn1/asn1c/ber_tlv_tag.c:33:2: parm_loop_bound: > > > Using > > > unsigned parameter "size" in a loop exit test. > > > #??273|???????????} > > > #??274| > > > #??275|->?????????tl = ber_fetch_tag(buf_ptr, Left, &tlv_tag); > > > #??276|???????????ASN_DEBUG("fetch tag(size=%ld,L=%ld), %sstack, > > > left=%ld, wn=%ld, tl=%ld", > > > #??277|???????????????(long)size, (long)Left, sel?"":"!", > > > > > > Error: FORWARD_NULL (CWE-476): [#def4] > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:583: var_compare_op: > > > Comparing > > > "st->buf" to null implies that "st->buf" might be null. > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:591: alias_transfer: > > > Assigning: > > > "buf" = "st->buf". > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:601: var_deref_op: > > > Dereferencing > > > null pointer "buf". > > > #??599|???????????????????p = scratch; > > > #??600|???????????????} > > > #??601|->?????????????*p++ = h2c[(*buf >> 4) & 0x0F]; > > > #??602|???????????????*p++ = h2c[*buf & 0x0F]; > > > #??603|???????????} > > > > > > Error: FORWARD_NULL (CWE-476): [#def5] > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:583: var_compare_op: > > > Comparing > > > "st->buf" to null implies that "st->buf" might be null. > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:591: alias_transfer: > > > Assigning: > > > "buf" = "st->buf". > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:615: var_deref_op: > > > Dereferencing > > > null pointer "buf". > > > #??613|???????????????????_i_ASN_TEXT_INDENT(1, ilevel); > > > #??614|???????????????} > > > #??615|->?????????????*p++ = h2c[(*buf >> 4) & 0x0F]; > > > #??616|???????????????*p++ = h2c[*buf & 0x0F]; > > > #??617|???????????????*p++ = 0x20; > > > > > > Error: FORWARD_NULL (CWE-476): [#def6] > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:739: var_compare_op: > > > Comparing > > > "st->buf" to null implies that "st->buf" might be null. > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:742: alias_transfer: > > > Assigning: > > > "buf" = "st->buf". > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:745: var_deref_op: > > > Dereferencing > > > null pointer "buf". > > > #??743|???????end = buf + st->size; > > > #??744|???????for(ss = buf; buf < end; buf++) { > > > #??745|->?????????unsigned int ch = *buf; > > > #??746|???????????int s_len;????/* Special encoding sequence > > > length */ > > > #??747| > > > > > > Error: FORWARD_NULL (CWE-476): [#def7] > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1659: var_compare_op: > > > Comparing > > > "st->buf" to null implies that "st->buf" might be null. > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1665: alias_transfer: > > > Assigning: > > > "buf" = "st->buf". > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1674: var_deref_op: > > > Dereferencing null pointer "buf". > > > # 1672|???????????????p = scratch; > > > # 1673|???????????} > > > # 1674|->?????????*p++ = h2c[(*buf >> 4) & 0x0F]; > > > # 1675|???????????*p++ = h2c[*buf & 0x0F]; > > > # 1676|???????????*p++ = 0x20; > > > > > > Error: REVERSE_INULL (CWE-476): [#def8] > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1706: deref_ptr: Directly > > > dereferencing pointer "td". > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1713: check_after_deref: > > > Null-checking "td" suggests that it may be null, but it has > > > already been > > > dereferenced on all paths leading to the check. > > > # 1711|???????struct _stack *stck; > > > # 1712| > > > # 1713|->?????if(!td || !st) > > > # 1714|???????????return; > > > # 1715| > > > > > > Error: DEADCODE (CWE-561): [#def9] > > > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:40: assignment: > > > Assigning: > > > "len" = "0L". > > > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:44: cond_at_least: > > > Condition > > > "len < 0L", taking false branch. Now the value of "len" is at > > > least 0. > > > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:54: assignment: > > > Assigning: > > > "lenplusepsilon" = "(size_t)len + 1024UL". > > > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:63: at_least: At > > > condition > > > "lenplusepsilon < 0L", the value of "lenplusepsilon" must be at > > > least 1024. > > > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:63: > > > dead_error_condition: The > > > condition "lenplusepsilon < 0L" cannot be true. > > > freeipa-4.4.0/asn1/asn1c/ber_tlv_length.c:65: dead_error_line: > > > Execution > > > cannot reach this statement: "return -1L;". > > > #???63|???????????????if(lenplusepsilon < 0) { > > > #???64|???????????????????/* Too large length value */ > > > #???65|->?????????????????return -1; > > > #???66|???????????????} > > > #???67| > > > > > > Error: REVERSE_INULL (CWE-476): [#def10] > > > freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:1034: deref_ptr: > > > Directly > > > dereferencing pointer "td". > > > freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:1037: check_after_deref: > > > Null-checking "td" suggests that it may be null, but it has > > > already been > > > dereferenced on all paths leading to the check. > > > # 1035|???????int present; > > > # 1036| > > > # 1037|->?????if(!td || !ptr) > > > # 1038|???????????return; > > > # 1039| > > > > > > Error: RESOURCE_LEAK (CWE-772): [#def11] > > > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1147: alloc_fn: > > > Storage is > > > returned from allocation function "malloc". > > > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1147: var_assign: > > > Assigning: > > > "epres" = storage returned from "malloc(bmlength + 15L >> 3)". > > > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1151: noescape: > > > Resource > > > "epres" is not freed or pointed-to in "per_get_many_bits". > > > freeipa-4.4.0/asn1/asn1c/per_support.c:123:48: noescape: > > > "per_get_many_bits(asn_per_data_t *, uint8_t *, int, int)" does > > > not free > > > or save its parameter "dst". > > > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1152: leaked_storage: > > > Variable "epres" going out of scope leaks the storage it points > > > to. > > > # 1150|???????????/* Get the extensions map */ > > > # 1151|???????????if(per_get_many_bits(pd, epres, 0, bmlength)) > > > # 1152|->?????????????_ASN_DECODE_STARVED; > > > # 1153| > > > # 1154|???????????memset(&epmd, 0, sizeof(epmd)); > > > > > > Error: CHECKED_RETURN (CWE-252): [#def12] > > > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1320: check_return: > > > Calling > > > "per_put_few_bits" without checking return value (as is done > > > elsewhere > > > 23 out of 28 times). > > > freeipa-4.4.0/asn1/asn1c/INTEGER.c:724: example_checked: Example > > > 1: > > > "per_put_few_bits(po, inext, 1)" has its value checked in > > > "per_put_few_bits(po, inext, 1)". > > > freeipa-4.4.0/asn1/asn1c/NativeEnumerated.c:180: example_checked: > > > Example 2: "per_put_few_bits(po, inext, 1)" has its value checked > > > in > > > "per_put_few_bits(po, inext, 1)". > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1307: example_checked: > > > Example > > > 3: "per_put_few_bits(po, ch, unit_bits)" has its value checked in > > > "per_put_few_bits(po, ch, unit_bits)". > > > freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:949: example_checked: > > > Example > > > 4: "per_put_few_bits(po, 1U, 1)" has its value checked in > > > "per_put_few_bits(po, 1U, 1)". > > > freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1282: example_checked: > > > Example 5: "per_put_few_bits(po1, present, 1)" has its value > > > checked in > > > "per_put_few_bits(po1, present, 1)". > > > # 1318|???????if(specs->ext_before >= 0) { > > > # 1319|???????????n_extensions = SEQUENCE_handle_extensions(td, > > > sptr, 0, 0); > > > # 1320|->?????????per_put_few_bits(po, n_extensions ? 1 : 0, 1); > > > # 1321|???????} else { > > > # 1322|???????????n_extensions = 0;????/* There are no extensions > > > to > > > encode */ > > > > > > Error: DEADCODE (CWE-561): [#def13] > > > freeipa-4.4.0/asn1/asn1c/per_encoder.c:126: cond_notnull: > > > Condition > > > "td", taking true branch. Now the value of "td" is not "NULL". > > > freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: notnull: At condition > > > "td", > > > the value of "td" cannot be "NULL". > > > freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: dead_error_condition: > > > The > > > condition "td" must be true. > > > freeipa-4.4.0/asn1/asn1c/per_encoder.c:146: dead_error_line: > > > Execution > > > cannot reach the expression """" inside this statement: > > > "ASN_DEBUG("Failed to encode...". > > > #??144| > > > #??145|???????????if(_uper_encode_flush_outp(&po)) > > > #??146|->?????????????_ASN_ENCODE_FAILED; > > > #??147|???????} > > > #??148| > > > > > > Error: DEADCODE (CWE-561): [#def14] > > > freeipa-4.4.0/asn1/asn1c/per_opentype.c:176: assignment: > > > Assigning: > > > "padding" = "pd->moved % 8UL". > > > freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: between: At > > > condition > > > "padding > 7L", the value of "padding" must be between 1 and 7. > > > freeipa-4.4.0/asn1/asn1c/per_opentype.c:177: cond_cannot_single: > > > Condition "padding", taking true branch. Now the value of > > > "padding" > > > cannot be equal to 0. > > > freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: cannot_single: At > > > condition > > > "padding > 7L", the value of "padding" cannot be equal to 0. > > > freeipa-4.4.0/asn1/asn1c/per_opentype.c:179: > > > dead_error_condition: The > > > condition "padding > 7L" cannot be true. > > > freeipa-4.4.0/asn1/asn1c/per_opentype.c:180: dead_error_begin: > > > Execution > > > cannot reach this statement: "ASN_DEBUG("Too large paddin...". > > > #??178|???????????int32_t pvalue; > > > #??179|???????????if(padding > 7) { > > > #??180|->?????????????ASN_DEBUG("Too large padding %d in open > > > type", > > > #??181|???????????????????(int)padding); > > > #??182|???????????????rv.code = RC_FAIL; > > > > > > Error: OVERRUN (CWE-119): [#def15] > > > freeipa-4.4.0/asn1/asn1c/per_support.c:14: assignment: Assigning: > > > "n" = > > > "(n + 1) % 2". The value of "n" is now between 0 and 1 > > > (inclusive). > > > freeipa-4.4.0/asn1/asn1c/per_support.c:15: overrun-buffer-arg: > > > Calling > > > "snprintf" with "buf[n]" and "64UL" is suspicious because the > > > function > > > call may access "buf" at byte "n * sizeof (char [32]) + 63UL". > > > [Note: > > > The source code implementation of the function has been > > > overridden by a > > > builtin model.] > > > #???13|???????static int n; > > > #???14|???????n = (n+1) % 2; > > > #???15|->?????snprintf(buf[n], sizeof(buf), > > > #???16|???????????"{m=%ld span %+ld[%d..%d] (%d)}", > > > #???17|???????????(long)pd->moved, > > > > > > Error: FORWARD_NULL (CWE-476): [#def16] > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1513: var_compare_op: > > > Comparing > > > "st->buf" to null implies that "st->buf" might be null. > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1618: alias_transfer: > > > Assigning: > > > "buf" = "st->buf". > > > freeipa-4.4.0/asn1/asn1c/OCTET_STRING.c:1631: var_deref_model: > > > Passing > > > null pointer "buf" to "per_put_many_bits", which dereferences it. > > > freeipa-4.4.0/asn1/asn1c/per_support.c:419:4: deref_parm: > > > Directly > > > dereferencing parameter "src". > > > #??417| > > > #??418|???????????if(nbits >= 24) { > > > #??419|->?????????????value = (src[0] << 16) | (src[1] << 8) | > > > src[2]; > > > #??420|???????????????src += 3; > > > #??421|???????????????nbits -= 24; > > > > I put missing files to makefile before push > > ACK > > master: > * 512aa90bec108a1d523ac5868342c68892f2c4cb Regenerate asn1 code > * cf0816f41503c9a556373b37b987dcb7a9be040b Additional coverity fixes. Thanks a lot! Simo. From pvoborni at redhat.com Tue Aug 16 10:42:59 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 16 Aug 2016 12:42:59 +0200 Subject: [Freeipa-devel] [PATCH] 0004 Added support for authentication with user certificate In-Reply-To: <7b5ac93b-e7d8-aa0e-3dd0-21eb7f6ef4e6@redhat.com> References: <57383c8e-c4c2-61ad-1045-9e9c20eab4d8@redhat.com> <7b5ac93b-e7d8-aa0e-3dd0-21eb7f6ef4e6@redhat.com> Message-ID: On 08/16/2016 10:17 AM, Jan Cholasta wrote: > On 12.8.2016 15:02, Petr Vobornik wrote: >> On 08/12/2016 02:54 PM, Tibor Dudlak wrote: >>> Hi, >>> >>> I have edited my previous patch. >>> >>> On Thu, Aug 11, 2016 at 11:52 AM, Jan Cholasta >> > wrote: >>> >>> Hi, >>> >>> On 11.8.2016 09:55, Tibor Dudlak wrote: >>> >>> Hi, >>> >>> ... >>> >>> >>> +class login_x509(login_kerberos, KerberosSession, HTTP_Status): >>> + key = '/session/login_x509' >>> >>> login_kerberos already subclasses KerberosSession and >>> HTTP_Status, no need >>> to do it again here. In fact, it would be best to split off the >>> bussiness >>> logic from login_kerberos into a separate class and inherit both >>> login_kerberos and login_x509 from it: >>> >>> class KerberosLogin(Backend, KerberosSession, HTTP_Status): >>> def _on_finalize(self): >>> ... >>> >>> def __call__(self, ...): >>> ... >>> >>> class login_kerberos(KerberosLogin): >>> key = '/session/login_kerberos' >>> >>> class login_x509(KerberosLogin): >>> key = '/session/login_x509' >>> >>> Honza >>> >>> -- >>> Jan Cholasta >>> >>> >>> Thank jcholast for review, it should be all right now. >>> >>> -- >>> Tibor Dudl?k >>> Intern - Identity management Special Projects >>> Red Hat >>> >> >> Tibor, please reuse the original thread and patch number in each patch >> iteration. But append new patch version. E.g. >> freeipa-ddudla-0003-2-Added... >> >> Starting new thread for each patch revision makes it hard to track. > > +1 > > As far as the patch is concerned, LGTM. > Anyway, I'd split the patch into two pieces: 1. the python part 2. the webui plugin + related conf Reason: there is a wide agreement that #1 will be push. It's not about #2. -- Petr Vobornik From mbasti at redhat.com Tue Aug 16 10:57:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 12:57:36 +0200 Subject: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts In-Reply-To: <63652041.43937962.1471257978245.JavaMail.zimbra@redhat.com> References: <256010841.13930537.1470754537126.JavaMail.zimbra@redhat.com> <2017998780.43897958.1471251308082.JavaMail.zimbra@redhat.com> <63652041.43937962.1471257978245.JavaMail.zimbra@redhat.com> Message-ID: On 15.08.2016 12:46, Ganna Kaihorodova wrote: > Hello! > I fixed typo in commit message. > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > ----- Original Message ----- > From: "Ganna Kaihorodova" > To: "Petr Spacek" > Cc: freeipa-devel at redhat.com > Sent: Monday, August 15, 2016 10:55:08 AM > Subject: Re: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts > > Hello, Petr! > > Yes, this is exactly what I meant. > Martin Basti educated me with that. > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > ----- Original Message ----- > From: "Petr Spacek" > To: freeipa-devel at redhat.com > Sent: Friday, August 12, 2016 6:58:54 PM > Subject: Re: [Freeipa-devel] [PATCH 0003][Tests] Fix for integration tests replication layouts > > On 9.8.2016 16:55, Ganna Kaihorodova wrote: >> Hello! >> >> Domain level 0 doesn't allow to create replica file on CA master, testcase was skipped with Domain level 0 > You mean on CA-less master, right? > > Petr^2 Spacek > >> https://fedorahosted.org/freeipa/ticket/6134 > > ACK Pushed to: master: 64c5340329b8eeaf7d8995a3c86b9bdf10ea9252 ipa-4-3: 0412cd3dcee7c89707c859d534f8fe81e154a344 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 16 11:03:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 13:03:29 +0200 Subject: [Freeipa-devel] [PATCH 0048] Remove sys.exit() from installer modules In-Reply-To: <4bc9d3ca-5081-8a0f-e813-57cf3d87371d@redhat.com> References: <91e234f8-554f-7efd-a399-d51db521a2fe@redhat.com> <9e9d6098-cbe2-3455-47c0-a21d1aea8ae5@redhat.com> <28420a22-04ad-b04c-4c25-bd9a71f9051f@redhat.com> <9171d38e-da4f-0693-1f53-767dc4dfe219@redhat.com> <5763ABED.9010102@redhat.com> <5763D892.20605@redhat.com> <3b048d9c-03c8-1675-0a3f-20e4b8e293c2@redhat.com> <92bbb69d-cba7-a820-8254-00b684cdbada@redhat.com> <9839e9d7-a967-1702-e226-8e216408d100@redhat.com> <4bc9d3ca-5081-8a0f-e813-57cf3d87371d@redhat.com> Message-ID: <571f20f6-0ec7-f35f-aaa1-bb9239bb500d@redhat.com> On 16.08.2016 12:06, Stanislav Laznicka wrote: > On 08/16/2016 08:36 AM, Stanislav Laznicka wrote: >> On 08/02/2016 01:08 PM, Stanislav Laznicka wrote: >>> On 07/28/2016 10:57 AM, Martin Basti wrote: >>>> Hello, >>>> >>>> suprisingly, patch needs rebase :) >>>> >>>> 1) >>>> Is the script error the right Exception? >>> I chose ScriptError because it's able to change the return value of >>> the script, which is necessary sometimes. RuntimeError, which may >>> seem more suitable, would not be able to do that. However, I am open >>> for ideas on which exception type to use. >>>> >>>> 2) >>>> Can you use rather raise Exception(), instead of raise Exception >>>> >>> Sure, please see the modified attached patch. >>>> 3) >>>> I really hate to print errors to STDOUT from modules and then just >>>> call exit(1) (duplicated evil), could you replace print('xxx') with >>>> raise AnException('xxx') >>> Did that, only kept those prints printing directly to stderr. Not >>> sure if those should be changed as well. >>> >> Bumping for review/opinions. >> > Also a self-NACK, there were some sys imports that should not have > been there anymore (thanks, mbasti). Attaching a fixed version. > You use RuntimeError in bindinstance.py, in other files you use ScriptError, is this RuntimeError on purpose there? Martin^2 From mbasti at redhat.com Tue Aug 16 11:20:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 13:20:44 +0200 Subject: [Freeipa-devel] [PATCH 0433-0434] Fix zone removal to respect forward configuration inheritance + Remove preserve_forwarding parameter from ldap_delete_zone2() In-Reply-To: References: Message-ID: On 12.08.2016 12:37, Petr Spacek wrote: > Hello, > > please review attached patch set. It fixes > https://fedorahosted.org/bind-dyndb-ldap/ticket/167 > > The code is also available on Github: > https://github.com/pspacek/bind-dyndb-ldap/tree/fix_root_zone_removal > > Patched SRPM: > https://pspacek.fedorapeople.org/bind-dyndb-ldap/bind-dyndb-ldap-10.0-3.fc24.src.rpm > > COPR build: > https://copr.fedorainfracloud.org/coprs/pspacek/bind-dyndb-ldap/build/440841/ > > Martin Basti, please build it also in @freeipa/freeipa-master COPR so CI can > pick it up. Thank you! > > > Patch set description: > Fix zone removal to respect forward configuration inheritance. > > Ad-hoc fwd_delete_table() calls did not respect inheritance hierarchy > in forwarding configuration. Now all manipulation with forward table > is done in fwd_configure_zone() and fully respects configuration inheritance. > > There is a trick: When removing or deactivating a zone, fwd_configure_zone() > is called with empty configuration set to simulate that the zone does > not have any explicit configuration. This triggers the inheritance > logic when necessary (i.e. for the root zone). > > https://fedorahosted.org/bind-dyndb-ldap/ticket/167 > https://github.com/pspacek/bind-dyndb-ldap/commit/d6e413c4cc88101b902d73e05e1ce35e2fe4aedd > > > > Remove preserve_forwarding parameter from ldap_delete_zone2(). > > The parameter was TRUE only when called from zone_security_change(). > zone_security_change() is calling ldap_delete_zone2() in exclusive mode > anyway so there is no need to optimize this. > > Removal of the parameter will make easier to centralize forwarding > configuration on one place. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/167 > https://github.com/pspacek/bind-dyndb-ldap/commit/b40976263460d8f4aeeec2a2a8f41cc54dcd0b28 > Works for me, but I haven't checked the code. Martin^2 From slaznick at redhat.com Tue Aug 16 11:30:39 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 16 Aug 2016 13:30:39 +0200 Subject: [Freeipa-devel] [PATCH 0048] Remove sys.exit() from installer modules In-Reply-To: <571f20f6-0ec7-f35f-aaa1-bb9239bb500d@redhat.com> References: <91e234f8-554f-7efd-a399-d51db521a2fe@redhat.com> <9e9d6098-cbe2-3455-47c0-a21d1aea8ae5@redhat.com> <28420a22-04ad-b04c-4c25-bd9a71f9051f@redhat.com> <9171d38e-da4f-0693-1f53-767dc4dfe219@redhat.com> <5763ABED.9010102@redhat.com> <5763D892.20605@redhat.com> <3b048d9c-03c8-1675-0a3f-20e4b8e293c2@redhat.com> <92bbb69d-cba7-a820-8254-00b684cdbada@redhat.com> <9839e9d7-a967-1702-e226-8e216408d100@redhat.com> <4bc9d3ca-5081-8a0f-e813-57cf3d87371d@redhat.com> <571f20f6-0ec7-f35f-aaa1-bb9239bb500d@redhat.com> Message-ID: On 08/16/2016 01:03 PM, Martin Basti wrote: > > > On 16.08.2016 12:06, Stanislav Laznicka wrote: >> On 08/16/2016 08:36 AM, Stanislav Laznicka wrote: >>> On 08/02/2016 01:08 PM, Stanislav Laznicka wrote: >>>> On 07/28/2016 10:57 AM, Martin Basti wrote: >>>>> Hello, >>>>> >>>>> suprisingly, patch needs rebase :) >>>>> >>>>> 1) >>>>> Is the script error the right Exception? >>>> I chose ScriptError because it's able to change the return value of >>>> the script, which is necessary sometimes. RuntimeError, which may >>>> seem more suitable, would not be able to do that. However, I am >>>> open for ideas on which exception type to use. >>>>> >>>>> 2) >>>>> Can you use rather raise Exception(), instead of raise Exception >>>>> >>>> Sure, please see the modified attached patch. >>>>> 3) >>>>> I really hate to print errors to STDOUT from modules and then just >>>>> call exit(1) (duplicated evil), could you replace print('xxx') >>>>> with raise AnException('xxx') >>>> Did that, only kept those prints printing directly to stderr. Not >>>> sure if those should be changed as well. >>>> >>> Bumping for review/opinions. >>> >> Also a self-NACK, there were some sys imports that should not have >> been there anymore (thanks, mbasti). Attaching a fixed version. >> > > You use RuntimeError in bindinstance.py, in other files you use > ScriptError, is this RuntimeError on purpose there? > > Martin^2 I used it there as there was one other function in the module that would raise it, too. Adding a patch that raises ScriptError in bindinstance.check_reverse_zones() as well if you think raising ScriptError here would be more appropriate. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0048-5-Remove-sys.exit-from-install-modules-and-scripts.patch Type: text/x-patch Size: 44093 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 16 11:30:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 13:30:45 +0200 Subject: [Freeipa-devel] [PATCH 0159] Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin In-Reply-To: References: Message-ID: On 12.08.2016 20:00, Petr Spacek wrote: > Hello, > > this is the last patch necessary to get all test_xmlrpc/test_dns_plugin tests > to pass! (I hope :-) > > Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin > > Class test_forward_zones in ipatests/test_xmlrpc/test_dns_plugin > was using DNS zone 'fwzone2.test.' and expected to get warning > 'Forwarding policy conflicts with some automatic empty zones.' > (aka 'DNSForwardPolicyConflictWithEmptyZone'). > > This does not make sense because 'test.' zone is not listed in IANA registry > 'Locally-Served DNS Zones': > > http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml > > To fix this I simply removed the warning from set of expected results. > > https://fedorahosted.org/freeipa/ticket/6213 > > > > NACK raise AssertionError( > VALUE % (doc, expected, got, stack) E AssertionError: assert_deepequal: expected != got. E 0014: dnsforwardzone_add: Create forward zone u'fwzone2.test.' with forwarders with default ("first") policy E expected = at 0x7f76f1225500> E got = u"query 'fwzone2.test. SOA': The DNS operation timed out after 10.0012469292 seconds" E path = (u'messages', 0, u'data', u'error') I don't think that this will work, you must use function to check list, not list containing lambda functions Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 16 11:55:09 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 13:55:09 +0200 Subject: [Freeipa-devel] [PATCH 0159] Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin In-Reply-To: References: Message-ID: On 16.08.2016 13:30, Martin Basti wrote: > > > > On 12.08.2016 20:00, Petr Spacek wrote: >> Hello, >> >> this is the last patch necessary to get all test_xmlrpc/test_dns_plugin tests >> to pass! (I hope :-) >> >> Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin >> >> Class test_forward_zones in ipatests/test_xmlrpc/test_dns_plugin >> was using DNS zone 'fwzone2.test.' and expected to get warning >> 'Forwarding policy conflicts with some automatic empty zones.' >> (aka 'DNSForwardPolicyConflictWithEmptyZone'). >> >> This does not make sense because 'test.' zone is not listed in IANA registry >> 'Locally-Served DNS Zones': >> >> http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml >> >> To fix this I simply removed the warning from set of expected results. >> >> https://fedorahosted.org/freeipa/ticket/6213 >> >> >> >> > > NACK > > raise AssertionError( > > VALUE % (doc, expected, got, stack) > E AssertionError: assert_deepequal: expected != got. > E 0014: dnsforwardzone_add: Create forward zone > u'fwzone2.test.' with forwarders with default ("first") policy > E expected = at 0x7f76f1225500> > E got = u"query 'fwzone2.test. SOA': The DNS > operation timed out after 10.0012469292 seconds" > E path = (u'messages', 0, u'data', u'error') > > > I don't think that this will work, you must use function to check > list, not list containing lambda functions > > > Martin^2 > > Sorry, my bad, it is just wrong expected message in lambda -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 16 12:26:38 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 14:26:38 +0200 Subject: [Freeipa-devel] [PATCH 0155] DNS server upgrade: do not fail when DNS server did not respond In-Reply-To: References: <44f963a2-5e4d-2d34-4e6d-b9b58d6c6f5e@redhat.com> Message-ID: <8f799c97-61be-cef7-5a11-7f1ed5c91c50@redhat.com> On 11.08.2016 17:38, Martin Basti wrote: > > > On 11.08.2016 15:18, Petr Spacek wrote: >> On 11.8.2016 15:08, Petr Spacek wrote: >>> Hello, >>> >>> DNS server upgrade: do not fail when DNS server did not respond >>> >>> Previously, update_dnsforward_emptyzones failed with an exeception if >>> DNS query failed for some reason. Now the error is logged and upgrade >>> continues. >>> >>> I assume that this is okay because the DNS query is used as heuristics >>> of last resort in the upgrade logic and failure to do so should not >>> have >>> catastrophics consequences: In the worst case, the admin needs to >>> manually change forwarding policy from 'first' to 'only'. >>> >>> In the end I have decided not to auto-start BIND because BIND >>> depends on >>> GSSAPI for authentication, which in turn depends on KDC ... Alternative >>> like reconfiguring BIND to use LDAPI+EXTERNAL and reconfiguring DS to >>> accept LDAP external bind from named user are too complicated. >>> >>> https://fedorahosted.org/freeipa/ticket/6205 >> Here is variant for master branch. Enjoy. >> > ACK > master: * f2fe35721967531257bc952b766a7c77e71be826 DNS server upgrade: do not fail when DNS server did not respond ipa-4-3: * 27534f8d7294536364147b18b76ecb2bac67870f DNS server upgrade: do not fail when DNS server did not respond From rajat.linux at gmail.com Tue Aug 16 12:28:50 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Tue, 16 Aug 2016 14:28:50 +0200 Subject: [Freeipa-devel] pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ilt-gif-ipa01.ipa.preprod.local user=aduser@corp.addomain.com Message-ID: Hi, I have done IPA AD trust between IPA and AD server. But trust is showing offline always. But we are able to get the AD user information. And able to grant the KRB ticket. # wbinfo --online-status BUILTIN : online IPA : online *CORP : offline* #id aduser at CORP.ADDOMAIN.COM uid=1007656917(aduser at corp.addomain.com) gid=1007656917( aduser at corp.addomain.com) groups=1007656917(aduser at corp.addomain.com ),1007715891(prg-msoffice2013pro(kms)@corp.addomain.com),1007663829( da-eeg-intra-read at corp.addomain.com),1007600513(domain users at corp.addomain.com) [root at ilt-gif-ipa01 ~]# kinit aduser at CORP.ADDOMAIN.COM Password for aduser at CORP.ADDOMAIN.COM: [root at ilt-gif-ipa01 ~]# [root at ilt-gif-ipa01 ~]# [root at ilt-gif-ipa01 ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: aduser at CORP.ADDOMAIN.COM Valid starting Expires Service principal 08/11/2016 13:11:35 08/11/2016 23:11:35 krbtgt/ CORP.ADDOMAIN.COM at CORP.ADDOMAIN.COM renew until 08/12/2016 13:11:29 [root at ilt-gif-ipa01 ~]# Form IPA client server we are able to get the all thinks ( KRB ticket/ user/groups ) [root at ilt-gif-ipa02 ~]# getent passwd aduser at CORP.addomain.COM aduser at corp.addomain.com:*:1007656917:1007656917:USER NAME:/home/ corp.addomain.com/aduser: [root at ilt-gif-ipa02 ~]# [root at ilt-gif-ipa02 ~]# getent group aduser at CORP.addomain.COM aduser at corp.addomain.com:*:1007656917: [root at ilt-gif-ipa02 ~]# [root at ilt-gif-ipa02 ~]# id aduser at CORP.addomain.COM uid=1007656917(aduser at corp.addomain.com) gid=1007656917( aduser at corp.addomain.com) groups=1007656917(aduser at corp.addomain.com ),1007715891(prg-msoffice2013pro(kms)@corp.addomain.com),1007663829( da-eeg-intra-read at corp.addomain.com),1007600513(domain users at corp.addomain.com),1007725088(tfs_users at corp.addomain.com) Also we are to ssh to IPA client on same machine or from some other machine with gss authentication. But using password authentication it?s failed to login. *ERROR:- pam_sss(sshd:auth): authentication failure; logname* kinit aduser at CORP.ADDOMAIN.COM Password for aduser at CORP.ADDOMAIN.COM: [root at ilt-gif-ipa02 ~]# ssh -vl aduser at corp.addomain.com ilt-gif-ipa02.ipa.preprod.local OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 60: Applying options for * debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p 22 ilt-gif-ipa02.ipa.preprod.local debug1: permanently_set_uid: 0/0 debug1: permanently_drop_suid: 0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA f0:e6:b2:66:c8:41:06:4e:83:a4:a2:c5:5a:57:24:66 debug1: Host 'ilt-gif-ipa02.ipa.preprod.local' is known and matches the ECDSA host key. debug1: Found key in /root/.ssh/known_hosts:3 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic *debug1: Authentication succeeded (gssapi-with-mic).* Authenticated to ilt-gif-ipa02.ipa.preprod.local (via proxy). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 Last login: Thu Aug 11 13:17:05 2016 from ilt-gif-ipa02.ipa.preprod.local RHN kickstart on 2014-10-16 -sh-4.2$ pwd /home/corp.addomain.com/aduser -sh-4.2$ who am i aduser at corp.addomain.com pts/3 2016-08-11 13:19 (ilt-gif-ipa02.ipa.preprod.local) -sh-4.2$ ]# ssh aduser at corp.addomain.com@ilt-gif-ipa02.ipa.preprod.local e600336 at corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password: Permission denied, please try again. e600336 at corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password: Can you please help me i am not able to login with AD user password authentication. /Rajat Gupta -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 16 12:34:51 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 14:34:51 +0200 Subject: [Freeipa-devel] [PATCH 0156] server upgrade: do not start BIND if it was not running before the upgrad In-Reply-To: <96f7f682-7570-490c-78cb-73069fec4d60@redhat.com> References: <81e85801-f9bd-1024-4c89-3fe2387271fc@redhat.com> <96f7f682-7570-490c-78cb-73069fec4d60@redhat.com> Message-ID: <1a5ccb2f-84b9-7dee-7fc5-67285a7d0f0e@redhat.com> On 11.08.2016 17:39, Martin Basti wrote: > > > > On 11.08.2016 15:10, Petr Spacek wrote: >> Hello, >> >> server upgrade: do not start BIND if it was not running before the upgrade >> >> https://fedorahosted.org/freeipa/ticket/6206 >> >> >> > ACK > > Pushed to master: d461f42f9581f4b3ec89d7e043effe9d17fb1baa -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Aug 16 12:44:01 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 16 Aug 2016 14:44:01 +0200 Subject: [Freeipa-devel] pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ilt-gif-ipa01.ipa.preprod.local user=aduser@corp.addomain.com In-Reply-To: References: Message-ID: <20160816124401.GH19596@hendrix> On Tue, Aug 16, 2016 at 02:28:50PM +0200, rajat gupta wrote: > Hi, > > > I have done IPA AD trust between IPA and AD server. But trust is showing > offline always. But we are able to get the AD user information. And able to > grant the KRB ticket. > > > > # wbinfo --online-status > BUILTIN : online > IPA : online > *CORP : offline* > > > #id aduser at CORP.ADDOMAIN.COM > uid=1007656917(aduser at corp.addomain.com) gid=1007656917( > aduser at corp.addomain.com) groups=1007656917(aduser at corp.addomain.com > ),1007715891(prg-msoffice2013pro(kms)@corp.addomain.com),1007663829( > da-eeg-intra-read at corp.addomain.com),1007600513(domain > users at corp.addomain.com) > > > [root at ilt-gif-ipa01 ~]# kinit aduser at CORP.ADDOMAIN.COM > Password for aduser at CORP.ADDOMAIN.COM: > [root at ilt-gif-ipa01 ~]# > [root at ilt-gif-ipa01 ~]# > [root at ilt-gif-ipa01 ~]# klist > Ticket cache: KEYRING:persistent:0:0 > Default principal: aduser at CORP.ADDOMAIN.COM > > Valid starting Expires Service principal > 08/11/2016 13:11:35 08/11/2016 23:11:35 krbtgt/ > CORP.ADDOMAIN.COM at CORP.ADDOMAIN.COM > renew until 08/12/2016 13:11:29 > [root at ilt-gif-ipa01 ~]# > > > > Form IPA client server we are able to get the all thinks ( KRB ticket/ > user/groups ) > > [root at ilt-gif-ipa02 ~]# getent passwd aduser at CORP.addomain.COM > aduser at corp.addomain.com:*:1007656917:1007656917:USER NAME:/home/ > corp.addomain.com/aduser: > [root at ilt-gif-ipa02 ~]# > > > [root at ilt-gif-ipa02 ~]# getent group aduser at CORP.addomain.COM > aduser at corp.addomain.com:*:1007656917: > [root at ilt-gif-ipa02 ~]# > > > [root at ilt-gif-ipa02 ~]# id aduser at CORP.addomain.COM > uid=1007656917(aduser at corp.addomain.com) gid=1007656917( > aduser at corp.addomain.com) groups=1007656917(aduser at corp.addomain.com > ),1007715891(prg-msoffice2013pro(kms)@corp.addomain.com),1007663829( > da-eeg-intra-read at corp.addomain.com),1007600513(domain > users at corp.addomain.com),1007725088(tfs_users at corp.addomain.com) > > > Also we are to ssh to IPA client on same machine or from some other > machine with gss authentication. But using password authentication it?s > failed to login. > > *ERROR:- pam_sss(sshd:auth): authentication failure; logname* > > > kinit aduser at CORP.ADDOMAIN.COM > Password for aduser at CORP.ADDOMAIN.COM: > > > > [root at ilt-gif-ipa02 ~]# ssh -vl aduser at corp.addomain.com > ilt-gif-ipa02.ipa.preprod.local > OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 60: Applying options for * > debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p > 22 ilt-gif-ipa02.ipa.preprod.local > debug1: permanently_set_uid: 0/0 > debug1: permanently_drop_suid: 0 > debug1: identity file /root/.ssh/id_rsa type -1 > debug1: identity file /root/.ssh/id_rsa-cert type -1 > debug1: identity file /root/.ssh/id_dsa type -1 > debug1: identity file /root/.ssh/id_dsa-cert type -1 > debug1: identity file /root/.ssh/id_ecdsa type -1 > debug1: identity file /root/.ssh/id_ecdsa-cert type -1 > debug1: identity file /root/.ssh/id_ed25519 type -1 > debug1: identity file /root/.ssh/id_ed25519-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.6.1 > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 > debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none > debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none > debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 > debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 > debug1: sending SSH2_MSG_KEX_ECDH_INIT > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug1: Server host key: ECDSA > f0:e6:b2:66:c8:41:06:4e:83:a4:a2:c5:5a:57:24:66 > debug1: Host 'ilt-gif-ipa02.ipa.preprod.local' is known and matches the > ECDSA host key. > debug1: Found key in /root/.ssh/known_hosts:3 > debug1: ssh_ecdsa_verify: signature correct > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug1: SSH2_MSG_NEWKEYS received > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic,password > debug1: Next authentication method: gssapi-keyex > debug1: No valid Key exchange context > debug1: Next authentication method: gssapi-with-mic > *debug1: Authentication succeeded (gssapi-with-mic).* > Authenticated to ilt-gif-ipa02.ipa.preprod.local (via proxy). > debug1: channel 0: new [client-session] > debug1: Requesting no-more-sessions at openssh.com > debug1: Entering interactive session. > debug1: Sending environment. > debug1: Sending env LANG = en_US.UTF-8 > Last login: Thu Aug 11 13:17:05 2016 from ilt-gif-ipa02.ipa.preprod.local > > RHN kickstart on 2014-10-16 > > -sh-4.2$ pwd > /home/corp.addomain.com/aduser > -sh-4.2$ who am i > aduser at corp.addomain.com pts/3 2016-08-11 13:19 > (ilt-gif-ipa02.ipa.preprod.local) > -sh-4.2$ > > > > ]# ssh aduser at corp.addomain.com@ilt-gif-ipa02.ipa.preprod.local > e600336 at corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password: > Permission denied, please try again. > e600336 at corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password: > > > Can you please help me i am not able to login with AD user > password authentication. This is the devel list, you're probably looking for the freeipa-users list: http://www.redhat.com/mailman/listinfo/freeipa-users and the best place to start debugging is: https://fedorahosted.org/sssd/wiki/Troubleshooting From abokovoy at redhat.com Tue Aug 16 12:46:14 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Aug 2016 15:46:14 +0300 Subject: [Freeipa-devel] pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ilt-gif-ipa01.ipa.preprod.local user=aduser@corp.addomain.com In-Reply-To: References: Message-ID: <20160816124614.dnoqxpzw6gsvblo6@redhat.com> On Tue, 16 Aug 2016, rajat gupta wrote: >Hi, > > >I have done IPA AD trust between IPA and AD server. But trust is showing >offline always. But we are able to get the AD user information. And able to >grant the KRB ticket. > > > ># wbinfo --online-status >BUILTIN : online >IPA : online >*CORP : offline* Don't use wbinfo. Its output is irrelevant starting from FreeIPA 3.3. > > >#id aduser at CORP.ADDOMAIN.COM >uid=1007656917(aduser at corp.addomain.com) gid=1007656917( >aduser at corp.addomain.com) groups=1007656917(aduser at corp.addomain.com >),1007715891(prg-msoffice2013pro(kms)@corp.addomain.com),1007663829( >da-eeg-intra-read at corp.addomain.com),1007600513(domain >users at corp.addomain.com) > > >[root at ilt-gif-ipa01 ~]# kinit aduser at CORP.ADDOMAIN.COM >Password for aduser at CORP.ADDOMAIN.COM: >[root at ilt-gif-ipa01 ~]# >[root at ilt-gif-ipa01 ~]# >[root at ilt-gif-ipa01 ~]# klist >Ticket cache: KEYRING:persistent:0:0 >Default principal: aduser at CORP.ADDOMAIN.COM > >Valid starting Expires Service principal >08/11/2016 13:11:35 08/11/2016 23:11:35 krbtgt/ >CORP.ADDOMAIN.COM at CORP.ADDOMAIN.COM > renew until 08/12/2016 13:11:29 >[root at ilt-gif-ipa01 ~]# This is irrelevant for the trust case because you are authenticating against AD DCs, not IPA KDCs. > > > >Form IPA client server we are able to get the all thinks ( KRB ticket/ >user/groups ) > >[root at ilt-gif-ipa02 ~]# getent passwd aduser at CORP.addomain.COM >aduser at corp.addomain.com:*:1007656917:1007656917:USER NAME:/home/ >corp.addomain.com/aduser: >[root at ilt-gif-ipa02 ~]# > > >[root at ilt-gif-ipa02 ~]# getent group aduser at CORP.addomain.COM >aduser at corp.addomain.com:*:1007656917: >[root at ilt-gif-ipa02 ~]# > > >[root at ilt-gif-ipa02 ~]# id aduser at CORP.addomain.COM >uid=1007656917(aduser at corp.addomain.com) gid=1007656917( >aduser at corp.addomain.com) groups=1007656917(aduser at corp.addomain.com >),1007715891(prg-msoffice2013pro(kms)@corp.addomain.com),1007663829( >da-eeg-intra-read at corp.addomain.com),1007600513(domain >users at corp.addomain.com),1007725088(tfs_users at corp.addomain.com) > > >Also we are to ssh to IPA client on same machine or from some other >machine with gss authentication. But using password authentication it?s >failed to login. > >*ERROR:- pam_sss(sshd:auth): authentication failure; logname* > > >kinit aduser at CORP.ADDOMAIN.COM >Password for aduser at CORP.ADDOMAIN.COM: > > > >[root at ilt-gif-ipa02 ~]# ssh -vl aduser at corp.addomain.com >ilt-gif-ipa02.ipa.preprod.local >OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013 >debug1: Reading configuration data /etc/ssh/ssh_config >debug1: /etc/ssh/ssh_config line 60: Applying options for * >debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p >22 ilt-gif-ipa02.ipa.preprod.local >debug1: permanently_set_uid: 0/0 >debug1: permanently_drop_suid: 0 >debug1: identity file /root/.ssh/id_rsa type -1 >debug1: identity file /root/.ssh/id_rsa-cert type -1 >debug1: identity file /root/.ssh/id_dsa type -1 >debug1: identity file /root/.ssh/id_dsa-cert type -1 >debug1: identity file /root/.ssh/id_ecdsa type -1 >debug1: identity file /root/.ssh/id_ecdsa-cert type -1 >debug1: identity file /root/.ssh/id_ed25519 type -1 >debug1: identity file /root/.ssh/id_ed25519-cert type -1 >debug1: Enabling compatibility mode for protocol 2.0 >debug1: Local version string SSH-2.0-OpenSSH_6.6.1 >debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 >debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 >debug1: SSH2_MSG_KEXINIT sent >debug1: SSH2_MSG_KEXINIT received >debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none >debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none >debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 >debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 >debug1: sending SSH2_MSG_KEX_ECDH_INIT >debug1: expecting SSH2_MSG_KEX_ECDH_REPLY >debug1: Server host key: ECDSA >f0:e6:b2:66:c8:41:06:4e:83:a4:a2:c5:5a:57:24:66 >debug1: Host 'ilt-gif-ipa02.ipa.preprod.local' is known and matches the >ECDSA host key. >debug1: Found key in /root/.ssh/known_hosts:3 >debug1: ssh_ecdsa_verify: signature correct >debug1: SSH2_MSG_NEWKEYS sent >debug1: expecting SSH2_MSG_NEWKEYS >debug1: SSH2_MSG_NEWKEYS received >debug1: SSH2_MSG_SERVICE_REQUEST sent >debug1: SSH2_MSG_SERVICE_ACCEPT received >debug1: Authentications that can continue: >publickey,gssapi-keyex,gssapi-with-mic,password >debug1: Next authentication method: gssapi-keyex >debug1: No valid Key exchange context >debug1: Next authentication method: gssapi-with-mic >*debug1: Authentication succeeded (gssapi-with-mic).* >Authenticated to ilt-gif-ipa02.ipa.preprod.local (via proxy). >debug1: channel 0: new [client-session] >debug1: Requesting no-more-sessions at openssh.com >debug1: Entering interactive session. >debug1: Sending environment. >debug1: Sending env LANG = en_US.UTF-8 >Last login: Thu Aug 11 13:17:05 2016 from ilt-gif-ipa02.ipa.preprod.local > >RHN kickstart on 2014-10-16 > >-sh-4.2$ pwd >/home/corp.addomain.com/aduser >-sh-4.2$ who am i >aduser at corp.addomain.com pts/3 2016-08-11 13:19 >(ilt-gif-ipa02.ipa.preprod.local) >-sh-4.2$ > > > >]# ssh aduser at corp.addomain.com@ilt-gif-ipa02.ipa.preprod.local >e600336 at corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password: >Permission denied, please try again. >e600336 at corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password: > > >Can you please help me i am not able to login with AD user >password authentication. If you cannot login with password but can with Kerberos credentials, you need to look into SSSD logs on the ilt-gif-ipa02.ipa.preprod.local host. See https://fedorahosted.org/sssd/wiki/Troubleshooting -- / Alexander Bokovoy From tdudlak at redhat.com Tue Aug 16 13:16:27 2016 From: tdudlak at redhat.com (Tibor Dudlak) Date: Tue, 16 Aug 2016 15:16:27 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> Message-ID: Hi, I have edited this patch after review. It should be okay now. Thank you. On Thu, Aug 11, 2016 at 7:49 PM, Petr Vobornik wrote: > On 08/11/2016 07:21 PM, Martin Basti wrote: > > > > > > On 11.08.2016 18:57, Pavel Vomacka wrote: > >> > >> > >> On 08/11/2016 02:00 PM, Petr Vobornik wrote: > >>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: > >>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: > >>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: > >>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: > >>>>>>> Got it. One thing I would correct, though, -- don't use > >>>>>>> kadmin.local, we > >>>>>>> do support setting ok_as_delegate on the service principals via IPA > >>>>>>> CLI: > >>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate > >>>>>>> --ok-as-delegate=BOOL > >>>>>>> Client credentials may be delegated to the > >>>>>>> service > >>>>>> I've tried > >>>>>> > >>>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) > >>>>>> > >>>>>> but that does not seem to have the same effect as > >>>>>> > >>>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test > >>>>>> > >>>>>> -- obtaining the delegated certificated fails. > >>>>> That's because ok_as_delegate and ok_to_auth_as_delegate are > different > >>>>> flags. > >>>> Right. The following patch adds ok_to_auth_as_delegate to the service > >>>> principal. > >>>> > >>>> I haven't added any tickets to it yet. > >>>> > >>>> > >>> This might deserve also nice Web UI checkbox similar to "Trusted for > >>> delegation". CCing Pavel. > >>> > >> Here is patch with new checkbox. It is without ticket in commit message > so > >> once we will have the ticket I will send another patch witch updated > commit > >> message. > > > > https://fedorahosted.org/freeipa/newticket > > > > ;-) > > It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 so we > might use that. > > > >> > >> > >> > > > > > > > > > -- > Petr Vobornik > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > -- Tibor Dudl?k Intern - Identity management Special Projects Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tdudlak-0001-2-Added-new-authentication-method.patch Type: text/x-patch Size: 2853 bytes Desc: not available URL: From tdudlak at redhat.com Tue Aug 16 13:19:18 2016 From: tdudlak at redhat.com (Tibor Dudlak) Date: Tue, 16 Aug 2016 15:19:18 +0200 Subject: [Freeipa-devel] [PATCH] 0004 Added support for authentication with user certificate In-Reply-To: References: <57383c8e-c4c2-61ad-1045-9e9c20eab4d8@redhat.com> <7b5ac93b-e7d8-aa0e-3dd0-21eb7f6ef4e6@redhat.com> Message-ID: Hi, I have done the python part, you can find it in original thread as you suggested. Thank you. On Tue, Aug 16, 2016 at 12:42 PM, Petr Vobornik wrote: > On 08/16/2016 10:17 AM, Jan Cholasta wrote: > > On 12.8.2016 15:02, Petr Vobornik wrote: > >> On 08/12/2016 02:54 PM, Tibor Dudlak wrote: > >>> Hi, > >>> > >>> I have edited my previous patch. > >>> > >>> On Thu, Aug 11, 2016 at 11:52 AM, Jan Cholasta >>> > wrote: > >>> > >>> Hi, > >>> > >>> On 11.8.2016 09:55, Tibor Dudlak wrote: > >>> > >>> Hi, > >>> > >>> ... > >>> > >>> > >>> +class login_x509(login_kerberos, KerberosSession, HTTP_Status): > >>> + key = '/session/login_x509' > >>> > >>> login_kerberos already subclasses KerberosSession and > >>> HTTP_Status, no need > >>> to do it again here. In fact, it would be best to split off the > >>> bussiness > >>> logic from login_kerberos into a separate class and inherit both > >>> login_kerberos and login_x509 from it: > >>> > >>> class KerberosLogin(Backend, KerberosSession, HTTP_Status): > >>> def _on_finalize(self): > >>> ... > >>> > >>> def __call__(self, ...): > >>> ... > >>> > >>> class login_kerberos(KerberosLogin): > >>> key = '/session/login_kerberos' > >>> > >>> class login_x509(KerberosLogin): > >>> key = '/session/login_x509' > >>> > >>> Honza > >>> > >>> -- > >>> Jan Cholasta > >>> > >>> > >>> Thank jcholast for review, it should be all right now. > >>> > >>> -- > >>> Tibor Dudl?k > >>> Intern - Identity management Special Projects > >>> Red Hat > >>> > >> > >> Tibor, please reuse the original thread and patch number in each patch > >> iteration. But append new patch version. E.g. > >> freeipa-ddudla-0003-2-Added... > >> > >> Starting new thread for each patch revision makes it hard to track. > > > > +1 > > > > As far as the patch is concerned, LGTM. > > > > Anyway, I'd split the patch into two pieces: > > 1. the python part > 2. the webui plugin + related conf > > Reason: there is a wide agreement that #1 will be push. It's not about #2. > > -- > Petr Vobornik > -- Tibor Dudl?k Intern - Identity management Special Projects Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From slaznick at redhat.com Tue Aug 16 13:47:56 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 16 Aug 2016 15:47:56 +0200 Subject: [Freeipa-devel] [PATCH 0063] Raise error on topology disconnect/last-role-host removal during server uninstall In-Reply-To: <448657e9-d35d-ffa9-8582-761c3d733aa9@redhat.com> References: <4b103ebb-cd29-1705-456f-fd7965abc2a6@redhat.com> <448657e9-d35d-ffa9-8582-761c3d733aa9@redhat.com> Message-ID: <647de12f-7f08-54c3-87c6-e56d34f236a3@redhat.com> On 08/15/2016 02:20 PM, Martin Babinsky wrote: > On 08/15/2016 02:13 PM, Martin Babinsky wrote: >> On 08/12/2016 12:08 PM, Stanislav Laznicka wrote: >>> Hello, >>> >>> topology disconnect/last-role-host removal errors would just be logged >>> during server uninstall even if ignore options are not present. The >>> host >>> would still appear in the topology even after "successful" uninstall. >>> >>> https://fedorahosted.org/freeipa/ticket/6168 >>> >>> >>> >> >> The patch seems to be ok, however shouldn't we use sys.exit() when >> handling ServerRemovalError? Yes raising SystemExit from within a >> function is a horrible practice, but it is already done on several other >> places instead of letting the exception bubble up to the main handler. >> >> CC'ing Jan for his thoughts on this since I may be wrong. >> > Hmm, you will definitely need sys.exit() here since otherwise > ipa-server-install reports 0 exit code even if there was an exception > thrown: > > """ > [root at master1 ~]# ipa-server-install --uninstall -U > ipa : ERROR Server removal aborted: Deleting this server > will leave your installation without a DNS.. > [root at master1 ~]# echo $? > 0 > """ > Because of #5750 (remove sys.exit() calls from installer modules) I rather raise ScriptError in this case. See the modified patch. It depends on either of my 48-4 or 48-5 patches (pick one). -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0063-2-Fail-on-topology-disconnect-last-role-removal.patch Type: text/x-patch Size: 1641 bytes Desc: not available URL: From ftweedal at redhat.com Tue Aug 16 14:09:39 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 17 Aug 2016 00:09:39 +1000 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <7ad5a28f-9670-b76a-f100-1a6681ac52e5@redhat.com> References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> <885c4c72-6e8a-4220-b25e-f577612368d2@redhat.com> <20160809144716.GA23927@dhcp-40-8.bne.redhat.com> <20160816052401.GR23927@dhcp-40-8.bne.redhat.com> <7ad5a28f-9670-b76a-f100-1a6681ac52e5@redhat.com> Message-ID: <20160816140939.GV23927@dhcp-40-8.bne.redhat.com> On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: > On 16.8.2016 07:24, Fraser Tweedale wrote: > > On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > > > On 9.8.2016 16:47, Fraser Tweedale wrote: > > > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > > > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > > > Please review the attached patch with adds --certificate-out and > > > > > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > > > > > > > > > Note that --certificate-chain-out currently writes a bogus file due > > > > > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > > > > > 1) The client-side *-out options should be defined on the client side, not > > > > > > > on the server side. > > > > > > > > > > > > > Will option defined on client side be propagated to, and observable > > > > > > in the ipaserver plugin? The ipaserver plugin needs to observe that > > > > > > *-out has been requested and executes additional command(s) on that > > > > > > basis. > > > > > > > > > > Is there a reason not to *always* return the certs? > > > > > > > > > We hit Dogtag to retrieve them. > > > > > > I don't think that's an issue in a -show command. > > > > > cert_show is invoked by other commands (cert_find*, cert_show, > > cert_request, cert_status, ca_del) but these all hit Dogtag anyway > > so I suppose that's fine. I'll return the cert *and* the chain in > > separate attributes, unconditionally. > > > > > > > > > > > > > > > > > > > > > > > > > > 2) I don't think there should be additional information included in summary > > > > > > > (and it definitely should not be multi-line). I would rather inform the user > > > > > > > via an error message when unable to write the files. > > > > > > > > > > > > > I was just following the pattern of other commands that write certs, > > > > > > profile config, etc. Apart from consistency with other commands I > > > > > > agree that there is no need to have it. So I will remove it. > > > > > > > > > > > > > If you think there is an actual value in informing the user about > > > > > > > successfully writing the files, please use ipalib.messages for the job. > > > > > > > > > > > > > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 would be > > > > > > > concatenated PEM, as that's the most commonly used format in IPA (in > > > > > > > installers, there are no cert chains in API commands ATM). > > > > > > > > > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > > > > > or concatenated PEMs, but sometimes they must be concatenated > > > > > > forward, and othertimes backwards. There is no one size fits all. > > > > > > > > > > True, which is exactly why I think we should at least be self-consistent and > > > > > use concatenated PEM (and multi-value DER over the wire). > > > > > > > > > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept > > > > header). > > > > > > > > If we want list-of-PEMs between server and client we have to convert > > > > on the server. Do we have a good way of doing this without exec'ing > > > > `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' > > > > to do the conversion on the server? python-nss does not have PKCS7 > > > > functions and I am not keen on adding a pyasn1 PKCS7 parser just for > > > > the sake of pushing bits as list-of-PEMs. > > > > > > I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other. > > > For example, if we added a call to retrieve external CA chain using certs > > > from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to > > > PKCS#7 if it was our cert chain format of choice. > > > > > > What we can avoid though is executing "openssl pkcs7" to do the conversion - > > > we can use an approach similar to our DNSSEC code and use python-cffi to > > > call libcrypto's PKCS#7 conversion routines instead. > > > > > I had a look at the OpenSSL API for parsing PKCS #7; now I prefer to > > exec `openssl' to do the job :) > > > > I will transmit DER-encoded PKCS #7 object on the wire; we cannot > > used multi-valued DER attribute because order is important. Client > > will convert to PEMs. > > Well, my point was not to send PKCS#7 over the wire, so that clients > (including 3rd party clients) do not have to convert from PKCS#7 themselves. > > In fact we can use multi-valued DER - whatever you send over the wire from > the server will be received in the exact same order by the client. Even if > it wasn't, you can easily restore the order by matching issuer and subject > names of the certificates. > > > > > Should have new patch on list this afternoon. > > > > Thanks, > > Fraser > > > > > > > > > > FWIW, man pages and code suggest that PKCS #7 is accepted in > > > > installer, etc. > > > > > > True, but that's a relatively new feature (since 4.1) and the installer > > > internally executes "openssl pkcs7" to convert PKCS #7 to list of certs :-) > > > > > > > > > > > > > We can add an option to control the format later, but for now, > > > > > > Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst > > > > > > case is an admin has to invoke `openssl pkcs7' and concat the certs > > > > > > themselves. > > > > > > > > > > AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, > > > > > so I'm afraid the worst case would happen virtually always. > > > > > > > > > If you're OK with invoking OpenSSL on the client to convert PKCS #7 > > > > to list-of-PEMs (similar to what is done in > > > > ipapython.certdb.NSSDatabase) then we can have the client perform > > > > the conversion. > > > > > > See above. > > > > > > > > > > > > > > > > > > > > > > > > > > > 4) Over the wire, the certs should be DER-formatted, as that's the most > > > > > > > common wire format in other API commands. > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > > > > > 5) What is the benefit in having the CA cert and the rest of the chain > > > > > > > separate? For end-entity certs it makes sense to separate the cert from the > > > > > > > CA chain, but for CA certs, you usually want the full chain, no? > > > > > > > > > > > > > If you want to anchor trust directly at a subca (e.g. restrict VPN > > > > > > login to certs issued by VPN sub-CA) then you often just want the > > > > > > cert. The chain option does subsume it, at cost of more work for > > > > > > administrators with this use case. I think it makes sense to keep > > > > > > both options. > > > > > > > > > > Does it? From what you described above, you either want just the sub-CA > > > > > cert, or the full chain including the sub-CA cert, in which case it might > > > > > make more sense to have a single --out option and a --chain flag. > > > > > > > > > How about --certificate-out which defaults to single cert, but does > > > > chain (as list-of-PEMs) when --chain flag given. > > > > > > > > Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more > > > > `--out' options. > > > > > > +1 > > > Updated patch 0097-2 attached, and new patch 0099 which must be applied first. I have implemented the suggested changes, except for cffi (I execute `openssl pkcs7' instead). There are two new output attributes on the wire, 'certificate' (single-value DER X.509), and 'certificate_chain' (ordered multi-value DER X.509). They are always returned. The first cert in the chain is always the same as 'certificate'; obviously this is redunant but I have left it this way because I think usage is clearer. Thanks, Fraser -------------- next part -------------- From 77d7d0185bcf3cb86f56bd128507a8e2cfedc775 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 16 Aug 2016 13:16:58 +1000 Subject: [PATCH] Add function for extracting PEM certs from PKCS #7 Add a single function for extracting X.509 certs in PEM format from a PKCS #7 object. Refactor sites that execute ``openssl pkcs7`` to use the new function. Part of: https://fedorahosted.org/freeipa/ticket/6178 --- ipalib/x509.py | 21 ++++++++++++++++- ipapython/certdb.py | 14 ++++------- ipaserver/install/cainstance.py | 52 +++++++++++++++-------------------------- 3 files changed, 43 insertions(+), 44 deletions(-) diff --git a/ipalib/x509.py b/ipalib/x509.py index 82194922d151a1b0f2df03df3578ad45b43b71c9..782519ce45e05e09d4dc02d41a537daab84db9e4 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -50,11 +50,12 @@ from ipalib import util from ipalib import errors from ipaplatform.paths import paths from ipapython.dn import DN +from ipapython import ipautil PEM = 0 DER = 1 -PEM_REGEX = re.compile(r'(?<=-----BEGIN CERTIFICATE-----).*?(?=-----END CERTIFICATE-----)', re.DOTALL) +PEM_REGEX = re.compile(r'-----BEGIN CERTIFICATE-----.*?-----END CERTIFICATE-----', re.DOTALL) EKU_SERVER_AUTH = '1.3.6.1.5.5.7.3.1' EKU_CLIENT_AUTH = '1.3.6.1.5.5.7.3.2' @@ -144,6 +145,24 @@ def load_certificate_list(data, dbdir=None): certs = [load_certificate(cert, PEM, dbdir) for cert in certs] return certs + +def pkcs7_to_pems(data, datatype=PEM): + """ + Extract certificates from a PKCS #7 object. + + Return a ``list`` of X.509 PEM strings. + + May throw ``ipautil.CalledProcessError`` on invalid data. + + """ + cmd = [ + paths.OPENSSL, "pkcs7", "-print_certs", + "-inform", "PEM" if datatype == PEM else "DER", + ] + result = ipautil.run(cmd, stdin=data, capture_output=True) + return PEM_REGEX.findall(result.output) + + def load_certificate_list_from_file(filename, dbdir=None): """ Load a certificate list from a PEM file. diff --git a/ipapython/certdb.py b/ipapython/certdb.py index e19f712d82f160ebc5de9c5b8d6627cb941c2cef..fd18023794a2daace60efd97aff54180b8409bbd 100644 --- a/ipapython/certdb.py +++ b/ipapython/certdb.py @@ -270,13 +270,11 @@ class NSSDatabase(object): continue if label in ('PKCS7', 'PKCS #7 SIGNED DATA', 'CERTIFICATE'): - args = [ - paths.OPENSSL, 'pkcs7', - '-print_certs', - ] try: - result = ipautil.run( - args, stdin=body, capture_output=True) + certs = x509.pkcs7_to_pems(body) + extracted_certs += '\n'.join(certs) + '\n' + loaded = True + continue except ipautil.CalledProcessError as e: if label == 'CERTIFICATE': root_logger.warning( @@ -287,10 +285,6 @@ class NSSDatabase(object): "Skipping PKCS#7 in %s at line %s: %s", filename, line, e) continue - else: - extracted_certs += result.output + '\n' - loaded = True - continue if label in ('PRIVATE KEY', 'ENCRYPTED PRIVATE KEY', 'RSA PRIVATE KEY', 'DSA PRIVATE KEY', diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 070498fe8a394802ea55f848a268e2b6563ec472..12c973c8acdcb0e657d92695dc28043b29966f2c 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -839,44 +839,30 @@ class CAInstance(DogtagInstance): # makes openssl throw up. data = base64.b64decode(chain) - result = ipautil.run( - [paths.OPENSSL, - "pkcs7", - "-inform", - "DER", - "-print_certs", - ], stdin=data, capture_output=True) - certlist = result.output + certlist = x509.pkcs7_to_pems(data, x509.DER) # Ok, now we have all the certificates in certs, walk through it # and pull out each certificate and add it to our database - st = 1 - en = 0 - subid = 0 ca_dn = DN(('CN','Certificate Authority'), self.subject_base) - while st > 0: - st = certlist.find('-----BEGIN', en) - en = certlist.find('-----END', en+1) - if st > 0: - try: - (chain_fd, chain_name) = tempfile.mkstemp() - os.write(chain_fd, certlist[st:en+25]) - os.close(chain_fd) - (_rdn, subject_dn) = certs.get_cert_nickname(certlist[st:en+25]) - if subject_dn == ca_dn: - nick = get_ca_nickname(self.realm) - trust_flags = 'CT,C,C' - else: - nick = str(subject_dn) - trust_flags = ',,' - self.__run_certutil( - ['-A', '-t', trust_flags, '-n', nick, '-a', - '-i', chain_name] - ) - finally: - os.remove(chain_name) - subid += 1 + for cert in certlist: + try: + (chain_fd, chain_name) = tempfile.mkstemp() + os.write(chain_fd, cert) + os.close(chain_fd) + (_rdn, subject_dn) = certs.get_cert_nickname(cert) + if subject_dn == ca_dn: + nick = get_ca_nickname(self.realm) + trust_flags = 'CT,C,C' + else: + nick = str(subject_dn) + trust_flags = ',,' + self.__run_certutil( + ['-A', '-t', trust_flags, '-n', nick, '-a', + '-i', chain_name] + ) + finally: + os.remove(chain_name) def __request_ra_certificate(self): # Create a noise file for generating our private key -- 2.5.5 -------------- next part -------------- From 4779e2cd4c30b896dbe914c095c0dbc068e38b63 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 8 Aug 2016 14:27:20 +1000 Subject: [PATCH] Add options to write lightweight CA cert or chain to file Administrators need a way to retrieve the certificate or certificate chain of an IPA-managed lightweight CA. Add output attributes to `ca_show' containing the CA certificate and chain (as multiple DER values), and add the `--certificate-out' option and `--chain' flag as client-side options for writing one or the other to a file. Fixes: https://fedorahosted.org/freeipa/ticket/6178 --- ipaclient/plugins/ca.py | 47 +++++++++++++++++++++++++++++++++++++++++++++ ipaserver/plugins/ca.py | 34 ++++++++++++++++++++++++++++---- ipaserver/plugins/dogtag.py | 12 ++++++++++++ 3 files changed, 89 insertions(+), 4 deletions(-) create mode 100644 ipaclient/plugins/ca.py diff --git a/ipaclient/plugins/ca.py b/ipaclient/plugins/ca.py new file mode 100644 index 0000000000000000000000000000000000000000..63770ff42af10f3f7d9419b692107433ddb35198 --- /dev/null +++ b/ipaclient/plugins/ca.py @@ -0,0 +1,47 @@ +# +# Copyright (C) 2016 FreeIPA Contributors see COPYING for license +# + +import base64 +from ipaclient.frontend import MethodOverride +from ipalib import util, x509, Flag, Str +from ipalib.plugable import Registry +from ipalib.text import _ + +register = Registry() + + + at register(override=True, no_fail=True) +class ca_show(MethodOverride): + + takes_options = ( + Str('certificate_out?', + doc=_('Write certificate to file'), + include='cli', + ), + Flag('chain', + default=False, + doc=_('Write certificate chain instead of single certificate'), + include='cli', + ), + ) + + def forward(self, *keys, **options): + filename = None + if 'certificate_out' in options: + filename = options.pop('certificate_out') + util.check_writable_file(filename) + chain = options.pop('chain', False) + + result = super(ca_show, self).forward(*keys, **options) + if filename: + to_pem = lambda x: x509.make_pem(base64.b64encode(x)) + if chain: + ders = result['result']['certificate_chain'] + data = '\n'.join(map(to_pem, ders)) + else: + data = to_pem(result['result']['certificate']) + with open(filename, 'wb') as f: + f.write(data) + + return result diff --git a/ipaserver/plugins/ca.py b/ipaserver/plugins/ca.py index 966ae2b1bdb4bb0207dfa58f0e9c951bc930f766..2e1787707bf002455478c969cd1914692c743b9c 100644 --- a/ipaserver/plugins/ca.py +++ b/ipaserver/plugins/ca.py @@ -2,14 +2,14 @@ # Copyright (C) 2016 FreeIPA Contributors see COPYING for license # -from ipalib import api, errors, DNParam, Str +from ipalib import api, errors, Bytes, DNParam, Str from ipalib.constants import IPA_CA_CN from ipalib.plugable import Registry from ipaserver.plugins.baseldap import ( LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, LDAPRetrieve) from ipaserver.plugins.cert import ca_enabled_check -from ipalib import _, ngettext +from ipalib import _, ngettext, x509 __doc__ = _(""" @@ -140,9 +140,35 @@ class ca_find(LDAPSearch): class ca_show(LDAPRetrieve): __doc__ = _("Display the properties of a CA.") - def execute(self, *args, **kwargs): + has_output_params = LDAPRetrieve.has_output_params + ( + Bytes( + 'certificate', + label=_("Certificate"), + doc=_("X.509 certificate"), + flags={'no_display'}, + ), + Bytes( + 'certificate_chain*', + label=_("Certificate chain"), + doc=_("PKCS #7 certificate chain"), + flags={'no_display'}, + ), + ) + + def execute(self, *keys, **options): ca_enabled_check() - return super(ca_show, self).execute(*args, **kwargs) + result = super(ca_show, self).execute(*keys, **options) + + ca_id = result['result']['ipacaid'][0] + with self.api.Backend.ra_lightweight_ca as ca_api: + result['result']['certificate'] = ca_api.read_ca_cert(ca_id) + + pkcs7_der = ca_api.read_ca_chain(ca_id) + pems = x509.pkcs7_to_pems(pkcs7_der, x509.DER) + ders = (x509.normalize_certificate(pem) for pem in pems) + result['result']['certificate_chain'] = list(ders) + + return result @register() diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index aef1e888eb1b6c273c1fd12cbf4912407f8f8132..1fd3106e0ae723eb30dbe32c61e637790f6085d2 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -2205,6 +2205,18 @@ class ra_lightweight_ca(RestClient): except: raise errors.RemoteRetrieveError(reason=_("Response from CA was not valid JSON")) + def read_ca_cert(self, ca_id): + status, resp_headers, resp_body = self._ssldo( + 'GET', '{}/cert'.format(ca_id), + headers={'Accept': 'application/pkix-cert'}) + return resp_body + + def read_ca_chain(self, ca_id): + status, resp_headers, resp_body = self._ssldo( + 'GET', '{}/chain'.format(ca_id), + headers={'Accept': 'application/pkcs7-mime'}) + return resp_body + def disable_ca(self, ca_id): self._ssldo( 'POST', ca_id + '/disable', -- 2.5.5 From pvomacka at redhat.com Tue Aug 16 15:00:54 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 16 Aug 2016 17:00:54 +0200 Subject: [Freeipa-devel] [PATCHES 681-682] cert: speed up cert-find, do not crash on invalid data in cert-find In-Reply-To: References: <5fdd4314-7c3f-242d-1648-0aae521f1743@redhat.com> <35ddad7d-664a-1231-c8ae-afd4d4b43443@redhat.com> Message-ID: <39d4c373-81b3-9379-d198-7bcb0bf42f0f@redhat.com> On 08/12/2016 08:29 AM, Jan Cholasta wrote: > On 11.8.2016 19:43, Martin Basti wrote: >> >> >> On 11.08.2016 16:09, Jan Cholasta wrote: >>> On 11.8.2016 14:27, Martin Basti wrote: >>>> >>>> >>>> On 01.08.2016 10:27, Jan Cholasta wrote: >>>>> On 1.8.2016 10:19, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patches fix >>>>>> >>>>>> and . >>>>> >>>>> Self-NACK, proper patches attached. >>>>> >>>>> Honza >>>>> >>>>> >>>>> >>>> >>>> IMHO this is caused by your patches, test_cert_plugin.py: >>> >>> Fixed. >>> >>> Updated and rebased patches attached. >>> >> Hello, >> >> It works for me, but: >> >> 1) >> Is this py2/3 compatible? >> ra_obj = ra.get_certificate(str(serial_number)) > > I don't see why not. Do you have any particular incompatibility in mind? > >> >> 2) >> Are you sure you need tuple() here? >> + for key in tuple(six.iterkeys(result)): > > Yes, I'm modifying `result` inside the loop. > > I don't need the six.iterkeys() though. > >> >> 3) >> if cert is not None: >> filter = ldap.make_filter_from_attr('usercertificate', >> value) >> filters.append(filter) >> >> Variable "value" may be referenced before assignment > > Right, it should be `cert`, not `value`. > >> >> I haven't tested performace improvements yet, and it is quite big change >> so I will continue with testing tomorrow. I tested performance improvements and cert-find in webui with 71 certificates took about 10 seconds before these patches, now it is about 400ms (even with more certs) . So works for me perfectly. From CLI it took about 10 seconds now around 4 seconds. >> >> Martin^2 > > -- Pavel^3 Vomacka From mbasti at redhat.com Tue Aug 16 15:01:37 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 17:01:37 +0200 Subject: [Freeipa-devel] [PATCHES 681-682] cert: speed up cert-find, do not crash on invalid data in cert-find In-Reply-To: <39d4c373-81b3-9379-d198-7bcb0bf42f0f@redhat.com> References: <5fdd4314-7c3f-242d-1648-0aae521f1743@redhat.com> <35ddad7d-664a-1231-c8ae-afd4d4b43443@redhat.com> <39d4c373-81b3-9379-d198-7bcb0bf42f0f@redhat.com> Message-ID: On 16.08.2016 17:00, Pavel Vomacka wrote: > > > On 08/12/2016 08:29 AM, Jan Cholasta wrote: >> On 11.8.2016 19:43, Martin Basti wrote: >>> >>> >>> On 11.08.2016 16:09, Jan Cholasta wrote: >>>> On 11.8.2016 14:27, Martin Basti wrote: >>>>> >>>>> >>>>> On 01.08.2016 10:27, Jan Cholasta wrote: >>>>>> On 1.8.2016 10:19, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the attached patches fix >>>>>>> >>>>>>> and . >>>>>> >>>>>> Self-NACK, proper patches attached. >>>>>> >>>>>> Honza >>>>>> >>>>>> >>>>>> >>>>> >>>>> IMHO this is caused by your patches, test_cert_plugin.py: >>>> >>>> Fixed. >>>> >>>> Updated and rebased patches attached. >>>> >>> Hello, >>> >>> It works for me, but: >>> >>> 1) >>> Is this py2/3 compatible? >>> ra_obj = ra.get_certificate(str(serial_number)) >> >> I don't see why not. Do you have any particular incompatibility in mind? >> >>> >>> 2) >>> Are you sure you need tuple() here? >>> + for key in tuple(six.iterkeys(result)): >> >> Yes, I'm modifying `result` inside the loop. >> >> I don't need the six.iterkeys() though. >> >>> >>> 3) >>> if cert is not None: >>> filter = ldap.make_filter_from_attr('usercertificate', >>> value) >>> filters.append(filter) >>> >>> Variable "value" may be referenced before assignment >> >> Right, it should be `cert`, not `value`. >> >>> >>> I haven't tested performace improvements yet, and it is quite big >>> change >>> so I will continue with testing tomorrow. > I tested performance improvements and cert-find in webui with 71 > certificates took about 10 seconds before these patches, now it is > about 400ms (even with more certs) . So works for me perfectly. From > CLI it took about 10 seconds now around 4 seconds. Please fix reported issues by me, and we can push it. >>> >>> Martin^2 >> >> From tkrizek at redhat.com Tue Aug 16 15:35:31 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Tue, 16 Aug 2016 17:35:31 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add Message-ID: Hi, the attached patch fixes an error message when user provides an empty key while adding otp token. https://fedorahosted.org/freeipa/ticket/6200 -- Tomas Krizek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tkrizek-0003-Validate-key-in-otptoken-add.patch Type: text/x-patch Size: 1046 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 16 16:23:40 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Aug 2016 18:23:40 +0200 Subject: [Freeipa-devel] [PATCH 0048] Remove sys.exit() from installer modules In-Reply-To: References: <91e234f8-554f-7efd-a399-d51db521a2fe@redhat.com> <9e9d6098-cbe2-3455-47c0-a21d1aea8ae5@redhat.com> <28420a22-04ad-b04c-4c25-bd9a71f9051f@redhat.com> <9171d38e-da4f-0693-1f53-767dc4dfe219@redhat.com> <5763ABED.9010102@redhat.com> <5763D892.20605@redhat.com> <3b048d9c-03c8-1675-0a3f-20e4b8e293c2@redhat.com> <92bbb69d-cba7-a820-8254-00b684cdbada@redhat.com> <9839e9d7-a967-1702-e226-8e216408d100@redhat.com> <4bc9d3ca-5081-8a0f-e813-57cf3d87371d@redhat.com> <571f20f6-0ec7-f35f-aaa1-bb9239bb500d@redhat.com> Message-ID: <8da68026-2027-491b-affe-308881614cd9@redhat.com> On 16.08.2016 13:30, Stanislav Laznicka wrote: > On 08/16/2016 01:03 PM, Martin Basti wrote: >> >> >> On 16.08.2016 12:06, Stanislav Laznicka wrote: >>> On 08/16/2016 08:36 AM, Stanislav Laznicka wrote: >>>> On 08/02/2016 01:08 PM, Stanislav Laznicka wrote: >>>>> On 07/28/2016 10:57 AM, Martin Basti wrote: >>>>>> Hello, >>>>>> >>>>>> suprisingly, patch needs rebase :) >>>>>> >>>>>> 1) >>>>>> Is the script error the right Exception? >>>>> I chose ScriptError because it's able to change the return value >>>>> of the script, which is necessary sometimes. RuntimeError, which >>>>> may seem more suitable, would not be able to do that. However, I >>>>> am open for ideas on which exception type to use. >>>>>> >>>>>> 2) >>>>>> Can you use rather raise Exception(), instead of raise Exception >>>>>> >>>>> Sure, please see the modified attached patch. >>>>>> 3) >>>>>> I really hate to print errors to STDOUT from modules and then >>>>>> just call exit(1) (duplicated evil), could you replace >>>>>> print('xxx') with raise AnException('xxx') >>>>> Did that, only kept those prints printing directly to stderr. Not >>>>> sure if those should be changed as well. >>>>> >>>> Bumping for review/opinions. >>>> >>> Also a self-NACK, there were some sys imports that should not have >>> been there anymore (thanks, mbasti). Attaching a fixed version. >>> >> >> You use RuntimeError in bindinstance.py, in other files you use >> ScriptError, is this RuntimeError on purpose there? >> >> Martin^2 > > I used it there as there was one other function in the module that > would raise it, too. Adding a patch that raises ScriptError in > bindinstance.check_reverse_zones() as well if you think raising > ScriptError here would be more appropriate. > ACK Pushed to master: 5776f1e90000ccfc24689c99951864248ed01045 From blipton at redhat.com Tue Aug 16 17:30:02 2016 From: blipton at redhat.com (Ben Lipton) Date: Tue, 16 Aug 2016 13:30:02 -0400 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> <837d2da8-d6ad-912a-2b72-a39e9cb87d15@redhat.com> Message-ID: <6315644a-a129-cc0a-7c5e-5f76b320a771@redhat.com> On 08/10/2016 08:52 AM, Ben Lipton wrote: > The pull request at https://github.com/LiptonB/freeipa/pull/4/commits > has been brought up to date (with a force push), and also includes 3 > more patches, described below. > > The patchset is also attached. To make sure that everything applies, I > just regenerated the whole set, though there may not be meaningful > changes. > After a discussion about how to address some of the concerns that have been voiced about this project, there have been some changes to the project direction. So, I wanted to provide an update about what the plans are. If you have objections or feel that I'm not representing it correctly, please let me know. Since we have yet to see all the ways people will want to use this feature, the immediate goal is to provide something that we can iterate on. To make this easier, we will avoid storing rule data on the server or modifying the server schema, as those changes would need to be supported long term/handled correctly on update. I plan to approach this as follows: - Separate the provider of mapping rules into a separate component from the generation of a config based on those rules - Build an alternative rule provider that reads local files rather than querying IPA - Move the implementation of CSR config formatting from the server API into a library (where should this go? ipalib? ipapython?), and then provide a client-side command that builds a config using the library. - Templates for at least two profiles ("user" profile with CN=, subject and email address SAN, "service" profile with CN=, subject and DNS SAN) will be provided. Users will be able to build custom profiles by putting files in the appropriate directories on their client machines (but we will not guarantee backward compatibility for the format of these files). - If we decide to move forward with storing rules on the server, the library call can be referenced from the server code, using the rule provider that pulls rules from the API. However, at that point we may also go in the direction of making automatic cert generation fully the responsibility of Dogtag, and keep the CSR-generation approach client-side only. Comments welcome! Unless the changes are more complex than I anticipate, I hope to have a prototype of this approach for review by the end of this week. Ben From abokovoy at redhat.com Tue Aug 16 18:12:56 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Aug 2016 21:12:56 +0300 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <6315644a-a129-cc0a-7c5e-5f76b320a771@redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> <837d2da8-d6ad-912a-2b72-a39e9cb87d15@redhat.com> <6315644a-a129-cc0a-7c5e-5f76b320a771@redhat.com> Message-ID: <20160816181256.p26yd3lvac5miuv3@redhat.com> On Tue, 16 Aug 2016, Ben Lipton wrote: >On 08/10/2016 08:52 AM, Ben Lipton wrote: >>The pull request at >>https://github.com/LiptonB/freeipa/pull/4/commits has been brought >>up to date (with a force push), and also includes 3 more patches, >>described below. >> >>The patchset is also attached. To make sure that everything applies, >>I just regenerated the whole set, though there may not be meaningful >>changes. >> >After a discussion about how to address some of the concerns that have >been voiced about this project, there have been some changes to the >project direction. So, I wanted to provide an update about what the >plans are. If you have objections or feel that I'm not representing it >correctly, please let me know. > >Since we have yet to see all the ways people will want to use this >feature, the immediate goal is to provide something that we can >iterate on. To make this easier, we will avoid storing rule data on >the server or modifying the server schema, as those changes would need >to be supported long term/handled correctly on update. I plan to >approach this as follows: >- Separate the provider of mapping rules into a separate component >from the generation of a config based on those rules >- Build an alternative rule provider that reads local files rather >than querying IPA >- Move the implementation of CSR config formatting from the server API >into a library (where should this go? ipalib? ipapython?), and then >provide a client-side command that builds a config using the library. Up to you -- ipapython is traditionally used for very basic dependencies when nothing is configured and is used by both installers and the framework, ipalib -- for common code in the framework itself. >- Templates for at least two profiles ("user" profile with >CN=, subject and email address SAN, "service" >profile with CN=, subject and DNS SAN) will be >provided. Users will be able to build custom profiles by putting files >in the appropriate directories on their client machines (but we will >not guarantee backward compatibility for the format of these files). >- If we decide to move forward with storing rules on the server, the >library call can be referenced from the server code, using the rule >provider that pulls rules from the API. However, at that point we may >also go in the direction of making automatic cert generation fully the >responsibility of Dogtag, and keep the CSR-generation approach >client-side only. > >Comments welcome! Unless the changes are more complex than I >anticipate, I hope to have a prototype of this approach for review by >the end of this week. The summary above looks fine. -- / Alexander Bokovoy From mkosek at redhat.com Tue Aug 16 19:04:22 2016 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Aug 2016 21:04:22 +0200 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <20160816181256.p26yd3lvac5miuv3@redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> <837d2da8-d6ad-912a-2b72-a39e9cb87d15@redhat.com> <6315644a-a129-cc0a-7c5e-5f76b320a771@redhat.com> <20160816181256.p26yd3lvac5miuv3@redhat.com> Message-ID: <52e165df-fdba-1e1d-4ea0-a81678a4aa03@redhat.com> On 08/16/2016 08:12 PM, Alexander Bokovoy wrote: > On Tue, 16 Aug 2016, Ben Lipton wrote: >> On 08/10/2016 08:52 AM, Ben Lipton wrote: >>> The pull request at https://github.com/LiptonB/freeipa/pull/4/commits has >>> been brought up to date (with a force push), and also includes 3 more >>> patches, described below. >>> >>> The patchset is also attached. To make sure that everything applies, I just >>> regenerated the whole set, though there may not be meaningful changes. >>> >> After a discussion about how to address some of the concerns that have been >> voiced about this project, there have been some changes to the project >> direction. So, I wanted to provide an update about what the plans are. If you >> have objections or feel that I'm not representing it correctly, please let me >> know. >> >> Since we have yet to see all the ways people will want to use this feature, >> the immediate goal is to provide something that we can iterate on. To make >> this easier, we will avoid storing rule data on the server or modifying the >> server schema, as those changes would need to be supported long term/handled >> correctly on update. I plan to approach this as follows: >> - Separate the provider of mapping rules into a separate component from the >> generation of a config based on those rules >> - Build an alternative rule provider that reads local files rather than >> querying IPA >> - Move the implementation of CSR config formatting from the server API into a >> library (where should this go? ipalib? ipapython?), and then provide a >> client-side command that builds a config using the library. > Up to you -- ipapython is traditionally used for very basic dependencies > when nothing is configured and is used by both installers and the > framework, ipalib -- for common code in the framework itself. > >> - Templates for at least two profiles ("user" profile with >> CN=, subject and email address SAN, "service" profile >> with CN=, subject and DNS SAN) will be provided. Users >> will be able to build custom profiles by putting files in the appropriate >> directories on their client machines (but we will not guarantee backward >> compatibility for the format of these files). >> - If we decide to move forward with storing rules on the server, the library >> call can be referenced from the server code, using the rule provider that >> pulls rules from the API. However, at that point we may also go in the >> direction of making automatic cert generation fully the responsibility of >> Dogtag, and keep the CSR-generation approach client-side only. >> >> Comments welcome! Unless the changes are more complex than I anticipate, I >> hope to have a prototype of this approach for review by the end of this week. > The summary above looks fine. +1, this looks good to me too. Thanks Ben, good job! Martin From jcholast at redhat.com Wed Aug 17 08:24:18 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Aug 2016 10:24:18 +0200 Subject: [Freeipa-devel] [PATCH 688] server install: do not prompt for cert file PIN repeatedly Message-ID: <79609ecc-aaf3-2388-a64d-379fcb0605a2@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-688-server-install-do-not-prompt-for-cert-file-PIN-repea.patch Type: text/x-patch Size: 4811 bytes Desc: not available URL: From jcholast at redhat.com Wed Aug 17 08:27:06 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Aug 2016 10:27:06 +0200 Subject: [Freeipa-devel] [PATCHES 681-682] cert: speed up cert-find, do not crash on invalid data in cert-find In-Reply-To: References: <5fdd4314-7c3f-242d-1648-0aae521f1743@redhat.com> <35ddad7d-664a-1231-c8ae-afd4d4b43443@redhat.com> <39d4c373-81b3-9379-d198-7bcb0bf42f0f@redhat.com> Message-ID: <08643229-deae-44a8-cacc-555df5d8ab41@redhat.com> On 16.8.2016 17:01, Martin Basti wrote: > > > On 16.08.2016 17:00, Pavel Vomacka wrote: >> >> >> On 08/12/2016 08:29 AM, Jan Cholasta wrote: >>> On 11.8.2016 19:43, Martin Basti wrote: >>>> >>>> >>>> On 11.08.2016 16:09, Jan Cholasta wrote: >>>>> On 11.8.2016 14:27, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 01.08.2016 10:27, Jan Cholasta wrote: >>>>>>> On 1.8.2016 10:19, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> the attached patches fix >>>>>>>> >>>>>>>> and . >>>>>>> >>>>>>> Self-NACK, proper patches attached. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> IMHO this is caused by your patches, test_cert_plugin.py: >>>>> >>>>> Fixed. >>>>> >>>>> Updated and rebased patches attached. >>>>> >>>> Hello, >>>> >>>> It works for me, but: >>>> >>>> 1) >>>> Is this py2/3 compatible? >>>> ra_obj = ra.get_certificate(str(serial_number)) >>> >>> I don't see why not. Do you have any particular incompatibility in mind? >>> >>>> >>>> 2) >>>> Are you sure you need tuple() here? >>>> + for key in tuple(six.iterkeys(result)): >>> >>> Yes, I'm modifying `result` inside the loop. >>> >>> I don't need the six.iterkeys() though. >>> >>>> >>>> 3) >>>> if cert is not None: >>>> filter = ldap.make_filter_from_attr('usercertificate', >>>> value) >>>> filters.append(filter) >>>> >>>> Variable "value" may be referenced before assignment >>> >>> Right, it should be `cert`, not `value`. >>> >>>> >>>> I haven't tested performace improvements yet, and it is quite big >>>> change >>>> so I will continue with testing tomorrow. >> I tested performance improvements and cert-find in webui with 71 >> certificates took about 10 seconds before these patches, now it is >> about 400ms (even with more certs) . So works for me perfectly. From >> CLI it took about 10 seconds now around 4 seconds. > > Please fix reported issues by me, and we can push it. Here you go. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-681.3-cert-speed-up-cert-find.patch Type: text/x-patch Size: 18415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-682.3-cert-do-not-crash-on-invalid-data-in-cert-find.patch Type: text/x-patch Size: 2598 bytes Desc: not available URL: From msehnout at redhat.com Wed Aug 17 08:26:57 2016 From: msehnout at redhat.com (Martin Sehnoutka) Date: Wed, 17 Aug 2016 10:26:57 +0200 Subject: [Freeipa-devel] [PATCH 0433-0434] Fix zone removal to respect forward configuration inheritance + Remove preserve_forwarding parameter from ldap_delete_zone2() In-Reply-To: References: Message-ID: <1250a1bd-15b2-f90d-8d40-e9e6351c9333@redhat.com> I checked the code. ACK Martin On 08/12/2016 12:37 PM, Petr Spacek wrote: > Hello, > > please review attached patch set. It fixes > https://fedorahosted.org/bind-dyndb-ldap/ticket/167 > > The code is also available on Github: > https://github.com/pspacek/bind-dyndb-ldap/tree/fix_root_zone_removal > > Patched SRPM: > https://pspacek.fedorapeople.org/bind-dyndb-ldap/bind-dyndb-ldap-10.0-3.fc24.src.rpm > > COPR build: > https://copr.fedorainfracloud.org/coprs/pspacek/bind-dyndb-ldap/build/440841/ > > Martin Basti, please build it also in @freeipa/freeipa-master COPR so CI can > pick it up. Thank you! > > > Patch set description: > Fix zone removal to respect forward configuration inheritance. > > Ad-hoc fwd_delete_table() calls did not respect inheritance hierarchy > in forwarding configuration. Now all manipulation with forward table > is done in fwd_configure_zone() and fully respects configuration inheritance. > > There is a trick: When removing or deactivating a zone, fwd_configure_zone() > is called with empty configuration set to simulate that the zone does > not have any explicit configuration. This triggers the inheritance > logic when necessary (i.e. for the root zone). > > https://fedorahosted.org/bind-dyndb-ldap/ticket/167 > https://github.com/pspacek/bind-dyndb-ldap/commit/d6e413c4cc88101b902d73e05e1ce35e2fe4aedd > > > > Remove preserve_forwarding parameter from ldap_delete_zone2(). > > The parameter was TRUE only when called from zone_security_change(). > zone_security_change() is calling ldap_delete_zone2() in exclusive mode > anyway so there is no need to optimize this. > > Removal of the parameter will make easier to centralize forwarding > configuration on one place. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/167 > https://github.com/pspacek/bind-dyndb-ldap/commit/b40976263460d8f4aeeec2a2a8f41cc54dcd0b28 > -- Martin Sehnoutka Associate Software Engineer Brno, Purky?ova 99 RED HAT | TRIED. TESTED. TRUSTED. From pspacek at redhat.com Wed Aug 17 08:34:50 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 17 Aug 2016 10:34:50 +0200 Subject: [Freeipa-devel] [PATCH 0433-0434] Fix zone removal to respect forward configuration inheritance + Remove preserve_forwarding parameter from ldap_delete_zone2() In-Reply-To: <1250a1bd-15b2-f90d-8d40-e9e6351c9333@redhat.com> References: <1250a1bd-15b2-f90d-8d40-e9e6351c9333@redhat.com> Message-ID: <581f2086-d5fb-4716-3ba0-8c37cce56aba@redhat.com> On 17.8.2016 10:26, Martin Sehnoutka wrote: > I checked the code. ACK Thanks, pushed to master: d6e413c4cc88101b902d73e05e1ce35e2fe4aedd Fix zone removal to respect forward configuration inheritance. b40976263460d8f4aeeec2a2a8f41cc54dcd0b28 Remove preserve_forwarding parameter from ldap_delete_zone2(). Petr^2 Spacek > > Martin > > On 08/12/2016 12:37 PM, Petr Spacek wrote: >> Hello, >> >> please review attached patch set. It fixes >> https://fedorahosted.org/bind-dyndb-ldap/ticket/167 >> >> The code is also available on Github: >> https://github.com/pspacek/bind-dyndb-ldap/tree/fix_root_zone_removal >> >> Patched SRPM: >> https://pspacek.fedorapeople.org/bind-dyndb-ldap/bind-dyndb-ldap-10.0-3.fc24.src.rpm >> >> COPR build: >> https://copr.fedorainfracloud.org/coprs/pspacek/bind-dyndb-ldap/build/440841/ >> >> Martin Basti, please build it also in @freeipa/freeipa-master COPR so CI can >> pick it up. Thank you! >> >> >> Patch set description: >> Fix zone removal to respect forward configuration inheritance. >> >> Ad-hoc fwd_delete_table() calls did not respect inheritance hierarchy >> in forwarding configuration. Now all manipulation with forward table >> is done in fwd_configure_zone() and fully respects configuration inheritance. >> >> There is a trick: When removing or deactivating a zone, fwd_configure_zone() >> is called with empty configuration set to simulate that the zone does >> not have any explicit configuration. This triggers the inheritance >> logic when necessary (i.e. for the root zone). >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/167 >> https://github.com/pspacek/bind-dyndb-ldap/commit/d6e413c4cc88101b902d73e05e1ce35e2fe4aedd >> >> >> >> Remove preserve_forwarding parameter from ldap_delete_zone2(). >> >> The parameter was TRUE only when called from zone_security_change(). >> zone_security_change() is calling ldap_delete_zone2() in exclusive mode >> anyway so there is no need to optimize this. >> >> Removal of the parameter will make easier to centralize forwarding >> configuration on one place. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/167 >> https://github.com/pspacek/bind-dyndb-ldap/commit/b40976263460d8f4aeeec2a2a8f41cc54dcd0b28 -- Petr^2 Spacek From mbabinsk at redhat.com Wed Aug 17 10:13:23 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 17 Aug 2016 12:13:23 +0200 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: <20160815160648.o2afooo4w5vycmt6@redhat.com> References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> Message-ID: On 08/15/2016 06:06 PM, Alexander Bokovoy wrote: > On Mon, 15 Aug 2016, Alexander Bokovoy wrote: >> Hi! >> >> Attached are trust-related patches. >> >> 0207 is a pre-requisite. I did send it before, it is re-formatting of >> the ipaserver/dcerpc.py to be close to PEP8 requirements. >> >> 0218 is an automated trust topology conflict resolver for DNS namespace >> conflicts. Read the commit message for details, and also comments in the >> code. With this patch FreeIPA becomes more smart than Windows Server >> which doesn't have automated trust topology conflict resolution. ;) >> >> 0219 fixes issue of topology details leaking through external trust. The >> problem is only in presentation as we store more data than needed -- it >> is impossible to cross external trust boundary anyway as it is handled >> by AD DC side, but one important consequence is that we need to store >> UPN suffixes before we start storing information about child domains. >> Again, read the commit message. >> >> These patches also are on top of my previously sent patches 0215-0216. > Patches attached. > > > Hi Alexander, patch 207: LGTM, but I have a feeling that the patch should be linked to both #6021 and #6076 so that it is not lost during backports. patch 218: ipalib/errors.py: 1.) I'm not sure if TrustTopologyConflictError should inherit from InvocationError. The semantics of InvocationError implies that something was wrong when trying to invoke the command (a param failed to validate/convert, incorrect number of args, etc.), while this is more of an exception during command execution (no. and type of params was correct, command started to execute but encountered an error condition). Thus I think it should inherit from ExecutionError. CC'ing Jan for more thoughts on this. 2.) Why is TrustTopologyConflictSolved listed amogn public errors? Since it is used only in dcerpc.py to restart trust establishment after resolving conflicts, it should be a private exception in dcerpc.py for this purpose. 3.) Also please split the exception format string like this so that the line is not too long (there is not much we can do about doctest so leave that line as it is): @@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): """ errno = 3017 - format = _("Forest '%(forest)s' has existing trust to forest(s) %(domains)s which prevents a trust to '%(conflict)s'") + format = _("Forest '%(forest)s' has existing trust to forest(s) " + "%(domains)s which prevents a trust to '%(conflict)s'") Do not worry about gettext, it can handle it just fine, there are plenty of examples in server plugins, for example. ipaserver/dcerpc.py: 1.) I think that instead of returning result and raising TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' can raise this exception directly. You can have an empty list defined at the beginning instead of 'result list', append unresolvable conflicts to it and then at the end of the method check if it is non-empty and raise the exception. 2.) + # In the code below: + # self -- the forest we establish trust to + # another_domain -- a forest that establishes trust to 'self' + # cinfo -- lsa_ForestTrustCollisionInfo structure that contain + # set of of lsa_ForestTrustCollisionRecord structures I would add this directly into the method docstring: """ ... :param self: the forest we establish trust to :param another_domain: a forest that establishes trust to 'self' :param cinfo: lsa_ForestTrustCollisionInfo structure that contain set of of lsa_ForestTrustCollisionRecord structures """ Additionally, the behavior specifed in previous comment can be added using :raises: stanza: """ :raises: errors.TrustTopologyConflictError if there are unresolvable namespace conflicts between trusted domains """ 3.) rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to simplify code in 'update_ftinfo' like this: """ - res = self.clear_ftinfo_conflict(another_domain, cinfo) - if len(res[1]) != 0: - domains = [x.name.string for x in res[1]] - raise errors.TrustTopologyConflictError( - target=self.info['dns_domain'], - conflict=another_domain.info['dns_domain'], - domains=domains) - else: - raise errors.TrustTopologyConflictSolved( - target=self.info['dns_domain'], - conflict=another_domain.info['dns_domain']) + self.clear_ftinfo_conflict(another_domain, cinfo) + raise errors.TrustTopologyConflictSolved( + target=self.info['dns_domain'], + conflict=another_domain.info['dns_domain']) """ Patch 218: 1.) typo in the commit message: """ ... suffixes are forest-wide, there *are could be* user accounts in the ... """ 2.) A stupid question I know, but why do we need to replace empty string with None here? """ # with the forest, thus we have to use netr_DsRGetForestTrustInformation - domains = netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], '', 0) + domains = netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], None, 0) """ -- Martin^3 Babinsky From mbabinsk at redhat.com Wed Aug 17 10:29:48 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 17 Aug 2016 12:29:48 +0200 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> Message-ID: <7d2e8eda-2aac-ad37-523a-38fd8a17a76f@redhat.com> On 08/17/2016 12:13 PM, Martin Babinsky wrote: > On 08/15/2016 06:06 PM, Alexander Bokovoy wrote: >> On Mon, 15 Aug 2016, Alexander Bokovoy wrote: >>> Hi! >>> >>> Attached are trust-related patches. >>> >>> 0207 is a pre-requisite. I did send it before, it is re-formatting of >>> the ipaserver/dcerpc.py to be close to PEP8 requirements. >>> >>> 0218 is an automated trust topology conflict resolver for DNS namespace >>> conflicts. Read the commit message for details, and also comments in the >>> code. With this patch FreeIPA becomes more smart than Windows Server >>> which doesn't have automated trust topology conflict resolution. ;) >>> >>> 0219 fixes issue of topology details leaking through external trust. The >>> problem is only in presentation as we store more data than needed -- it >>> is impossible to cross external trust boundary anyway as it is handled >>> by AD DC side, but one important consequence is that we need to store >>> UPN suffixes before we start storing information about child domains. >>> Again, read the commit message. >>> >>> These patches also are on top of my previously sent patches 0215-0216. >> Patches attached. >> >> >> > > Hi Alexander, > > patch 207: LGTM, but I have a feeling that the patch should be linked to > both #6021 and #6076 so that it is not lost during backports. > > patch 218: > > ipalib/errors.py: > > 1.) > I'm not sure if TrustTopologyConflictError should inherit from > InvocationError. The semantics of InvocationError implies that something > was wrong when trying to invoke the command (a param failed to > validate/convert, incorrect number of args, etc.), while this is more of > an exception during command execution (no. and type of params was > correct, command started to execute but encountered an error condition). > Thus I think it should inherit from ExecutionError. CC'ing Jan for more > thoughts on this. > > 2.) > > Why is TrustTopologyConflictSolved listed amogn public errors? Since it > is used only in dcerpc.py to restart trust establishment after resolving > conflicts, it should be a private exception in dcerpc.py for this purpose. > > 3.) > Also please split the exception format string like this so that the line > is not too long (there is not much we can do about doctest so leave that > line as it is): > > @@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): > """ > > errno = 3017 > - format = _("Forest '%(forest)s' has existing trust to forest(s) > %(domains)s which prevents a trust to '%(conflict)s'") > + format = _("Forest '%(forest)s' has existing trust to forest(s) " > + "%(domains)s which prevents a trust to '%(conflict)s'") > > Do not worry about gettext, it can handle it just fine, there are plenty > of examples in server plugins, for example. > > > ipaserver/dcerpc.py: > > 1.) > > I think that instead of returning result and raising > TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' > can raise this exception directly. You can have an empty list defined at > the beginning instead of 'result list', append unresolvable conflicts to > it and then at the end of the method check if it is non-empty and raise > the exception. > > 2.) > > + # In the code below: > + # self -- the forest we establish trust to > + # another_domain -- a forest that establishes trust to 'self' > + # cinfo -- lsa_ForestTrustCollisionInfo structure that contain > + # set of of lsa_ForestTrustCollisionRecord structures > I would add this directly into the method docstring: > > """ > ... > > :param self: the forest we establish trust to > :param another_domain: a forest that establishes trust to 'self' > :param cinfo: lsa_ForestTrustCollisionInfo structure that contain > set of of lsa_ForestTrustCollisionRecord structures > """ > > Additionally, the behavior specifed in previous comment can be added > using :raises: stanza: > > """ > :raises: errors.TrustTopologyConflictError if there are unresolvable > namespace conflicts between trusted domains > """ > > 3.) > > rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to > simplify code in 'update_ftinfo' like this: > > """ > - res = self.clear_ftinfo_conflict(another_domain, cinfo) > - if len(res[1]) != 0: > - domains = [x.name.string for x in res[1]] > - raise errors.TrustTopologyConflictError( > - target=self.info['dns_domain'], > - conflict=another_domain.info['dns_domain'], > - domains=domains) > - else: > - raise errors.TrustTopologyConflictSolved( > - target=self.info['dns_domain'], > - conflict=another_domain.info['dns_domain']) > + self.clear_ftinfo_conflict(another_domain, cinfo) > + raise errors.TrustTopologyConflictSolved( > + target=self.info['dns_domain'], > + conflict=another_domain.info['dns_domain']) > """ > > Patch 218: > > 1.) > typo in the commit message: > > """ > ... > suffixes are forest-wide, there *are could be* user accounts in the > ... > """ > > 2.) > A stupid question I know, but why do we need to replace empty string > with None here? > > """ > # with the forest, thus we have to use > netr_DsRGetForestTrustInformation > - domains = > netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], '', 0) > + domains = > netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], None, 0) > """ > Also I just noticed some pylint errors when doing build: Pylint is running, please wait ... ************* Module ipaserver.dcerpc ipaserver/dcerpc.py:58: [E0401(import-error), ] Unable to import 'pysss_nss_idmap') ipaserver/dcerpc.py:59: [E0401(import-error), ] Unable to import 'pysss') ipaserver/dcerpc.py:1202: [E1305(too-many-format-args), TrustDomainInstance.clear_ftinfo_conflict] Too many arguments for format string) ipaserver/dcerpc.py:1207: [E0602(undefined-variable), TrustDomainInstance.clear_ftinfo_conflict] Undefined variable 'conflict_type') Makefile:137: recipe for target 'pylint' failed You can probably ignore the first two since they may be caused by my broken build environment. -- Martin^3 Babinsky From mbasti at redhat.com Wed Aug 17 10:30:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 17 Aug 2016 12:30:03 +0200 Subject: [Freeipa-devel] [PATCH 0158] DNS: allow to add forward zone to already broken sub-domain In-Reply-To: References: Message-ID: On 12.08.2016 17:10, Petr Spacek wrote: > Hello, > > DNS: allow to add forward zone to already broken sub-domain > > Errors during DNS resolution might indicate that forwarder is the > necessary configuration which is missing. Now we disallow adding a > forwarder only if the zone is normally resolvable without the forwarder. > > https://fedorahosted.org/freeipa/ticket/6062 > > > ACK Pushed to master: b73ef3d7f9c757f1161db6801aadef52dd323195 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Aug 17 10:35:07 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 17 Aug 2016 12:35:07 +0200 Subject: [Freeipa-devel] [PATCH 0435-0436] Preparation for bind-dyndb-ldap 10.1 release Message-ID: <5e50a690-d351-533c-d685-612e95646951@redhat.com> Hello, Pushed to master: d7ae9e2e0206f770dd252c81abdc8b1be3fd30e2 Bump NVR to 10.1. fddb67672e458c8cbb0fd7997e42f94adb288181 Update NEWS for upcoming 10.1 release. Tagged as v10.1. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0435-Update-NEWS-for-upcoming-10.1-release.patch Type: text/x-patch Size: 798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0436-Bump-NVR-to-10.1.patch Type: text/x-patch Size: 1151 bytes Desc: not available URL: From abokovoy at redhat.com Wed Aug 17 10:41:07 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Aug 2016 13:41:07 +0300 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> Message-ID: <20160817104107.yew3cbsfojeqkwr2@redhat.com> On Wed, 17 Aug 2016, Martin Babinsky wrote: >On 08/15/2016 06:06 PM, Alexander Bokovoy wrote: >>On Mon, 15 Aug 2016, Alexander Bokovoy wrote: >>>Hi! >>> >>>Attached are trust-related patches. >>> >>>0207 is a pre-requisite. I did send it before, it is re-formatting of >>>the ipaserver/dcerpc.py to be close to PEP8 requirements. >>> >>>0218 is an automated trust topology conflict resolver for DNS namespace >>>conflicts. Read the commit message for details, and also comments in the >>>code. With this patch FreeIPA becomes more smart than Windows Server >>>which doesn't have automated trust topology conflict resolution. ;) >>> >>>0219 fixes issue of topology details leaking through external trust. The >>>problem is only in presentation as we store more data than needed -- it >>>is impossible to cross external trust boundary anyway as it is handled >>>by AD DC side, but one important consequence is that we need to store >>>UPN suffixes before we start storing information about child domains. >>>Again, read the commit message. >>> >>>These patches also are on top of my previously sent patches 0215-0216. >>Patches attached. >> >> >> > >Hi Alexander, > >patch 207: LGTM, but I have a feeling that the patch should be linked >to both #6021 and #6076 so that it is not lost during backports. > >patch 218: > >ipalib/errors.py: > >1.) >I'm not sure if TrustTopologyConflictError should inherit from >InvocationError. The semantics of InvocationError implies that >something was wrong when trying to invoke the command (a param failed >to validate/convert, incorrect number of args, etc.), while this is >more of an exception during command execution (no. and type of params >was correct, command started to execute but encountered an error >condition). Thus I think it should inherit from ExecutionError. CC'ing >Jan for more thoughts on this. > >2.) > >Why is TrustTopologyConflictSolved listed amogn public errors? Since >it is used only in dcerpc.py to restart trust establishment after >resolving conflicts, it should be a private exception in dcerpc.py for >this purpose. > >3.) >Also please split the exception format string like this so that the >line is not too long (there is not much we can do about doctest so >leave that line as it is): > >@@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): > """ > > errno = 3017 >- format = _("Forest '%(forest)s' has existing trust to forest(s) >%(domains)s which prevents a trust to '%(conflict)s'") >+ format = _("Forest '%(forest)s' has existing trust to forest(s) " >+ "%(domains)s which prevents a trust to '%(conflict)s'") > >Do not worry about gettext, it can handle it just fine, there are >plenty of examples in server plugins, for example. > > >ipaserver/dcerpc.py: > >1.) > >I think that instead of returning result and raising >TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' >can raise this exception directly. You can have an empty list defined >at the beginning instead of 'result list', append unresolvable >conflicts to it and then at the end of the method check if it is >non-empty and raise the exception. > >2.) > >+ # In the code below: >+ # self -- the forest we establish trust to >+ # another_domain -- a forest that establishes trust to 'self' >+ # cinfo -- lsa_ForestTrustCollisionInfo structure that contain >+ # set of of lsa_ForestTrustCollisionRecord structures >I would add this directly into the method docstring: > >""" >... > >:param self: the forest we establish trust to >:param another_domain: a forest that establishes trust to 'self' >:param cinfo: lsa_ForestTrustCollisionInfo structure that contain > set of of lsa_ForestTrustCollisionRecord structures >""" > >Additionally, the behavior specifed in previous comment can be added >using :raises: stanza: > >""" >:raises: errors.TrustTopologyConflictError if there are unresolvable > namespace conflicts between trusted domains >""" > >3.) > >rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to >simplify code in 'update_ftinfo' like this: > >""" >- res = self.clear_ftinfo_conflict(another_domain, cinfo) >- if len(res[1]) != 0: >- domains = [x.name.string for x in res[1]] >- raise errors.TrustTopologyConflictError( >- target=self.info['dns_domain'], >- conflict=another_domain.info['dns_domain'], >- domains=domains) >- else: >- raise errors.TrustTopologyConflictSolved( >- target=self.info['dns_domain'], >- conflict=another_domain.info['dns_domain']) >+ self.clear_ftinfo_conflict(another_domain, cinfo) >+ raise errors.TrustTopologyConflictSolved( >+ target=self.info['dns_domain'], >+ conflict=another_domain.info['dns_domain']) >""" > >Patch 218: > >1.) >typo in the commit message: > >""" >... >suffixes are forest-wide, there *are could be* user accounts in the >... >""" > >2.) >A stupid question I know, but why do we need to replace empty string >with None here? > >""" > # with the forest, thus we have to use >netr_DsRGetForestTrustInformation >- domains = >netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], '', 0) >+ domains = >netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], None, 0) >""" I'm answering this one while working on the other fixes. netr_DsRGetForestTrustInformation() uses NULL to say a parameter is missing, not empty string. It actually causes an issue if we don't do that when asking a domain controller from a domain that is not a root domain of the forest where we get currently undocumented error NERR_ACFNotLoaded (0x000008b3). If non-NULL name is specified, AD domain controller will perform proper operation only if it is a domain controller from the forest root domain and the domain specified is known. Obviously, a domain named '' cannot be known. This breaks external trust. Perhaps, this could be moved into a separate patch on its own. > >-- >Martin^3 Babinsky -- / Alexander Bokovoy From abokovoy at redhat.com Wed Aug 17 10:45:39 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Aug 2016 13:45:39 +0300 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: <7d2e8eda-2aac-ad37-523a-38fd8a17a76f@redhat.com> References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> <7d2e8eda-2aac-ad37-523a-38fd8a17a76f@redhat.com> Message-ID: <20160817104539.gasghalqx7byghts@redhat.com> On Wed, 17 Aug 2016, Martin Babinsky wrote: >On 08/17/2016 12:13 PM, Martin Babinsky wrote: >>On 08/15/2016 06:06 PM, Alexander Bokovoy wrote: >>>On Mon, 15 Aug 2016, Alexander Bokovoy wrote: >>>>Hi! >>>> >>>>Attached are trust-related patches. >>>> >>>>0207 is a pre-requisite. I did send it before, it is re-formatting of >>>>the ipaserver/dcerpc.py to be close to PEP8 requirements. >>>> >>>>0218 is an automated trust topology conflict resolver for DNS namespace >>>>conflicts. Read the commit message for details, and also comments in the >>>>code. With this patch FreeIPA becomes more smart than Windows Server >>>>which doesn't have automated trust topology conflict resolution. ;) >>>> >>>>0219 fixes issue of topology details leaking through external trust. The >>>>problem is only in presentation as we store more data than needed -- it >>>>is impossible to cross external trust boundary anyway as it is handled >>>>by AD DC side, but one important consequence is that we need to store >>>>UPN suffixes before we start storing information about child domains. >>>>Again, read the commit message. >>>> >>>>These patches also are on top of my previously sent patches 0215-0216. >>>Patches attached. >>> >>> >>> >> >>Hi Alexander, >> >>patch 207: LGTM, but I have a feeling that the patch should be linked to >>both #6021 and #6076 so that it is not lost during backports. >> >>patch 218: >> >>ipalib/errors.py: >> >>1.) >>I'm not sure if TrustTopologyConflictError should inherit from >>InvocationError. The semantics of InvocationError implies that something >>was wrong when trying to invoke the command (a param failed to >>validate/convert, incorrect number of args, etc.), while this is more of >>an exception during command execution (no. and type of params was >>correct, command started to execute but encountered an error condition). >>Thus I think it should inherit from ExecutionError. CC'ing Jan for more >>thoughts on this. >> >>2.) >> >>Why is TrustTopologyConflictSolved listed amogn public errors? Since it >>is used only in dcerpc.py to restart trust establishment after resolving >>conflicts, it should be a private exception in dcerpc.py for this purpose. >> >>3.) >>Also please split the exception format string like this so that the line >>is not too long (there is not much we can do about doctest so leave that >>line as it is): >> >>@@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): >> """ >> >> errno = 3017 >>- format = _("Forest '%(forest)s' has existing trust to forest(s) >>%(domains)s which prevents a trust to '%(conflict)s'") >>+ format = _("Forest '%(forest)s' has existing trust to forest(s) " >>+ "%(domains)s which prevents a trust to '%(conflict)s'") >> >>Do not worry about gettext, it can handle it just fine, there are plenty >>of examples in server plugins, for example. >> >> >>ipaserver/dcerpc.py: >> >>1.) >> >>I think that instead of returning result and raising >>TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' >>can raise this exception directly. You can have an empty list defined at >>the beginning instead of 'result list', append unresolvable conflicts to >>it and then at the end of the method check if it is non-empty and raise >>the exception. >> >>2.) >> >>+ # In the code below: >>+ # self -- the forest we establish trust to >>+ # another_domain -- a forest that establishes trust to 'self' >>+ # cinfo -- lsa_ForestTrustCollisionInfo structure that contain >>+ # set of of lsa_ForestTrustCollisionRecord structures >>I would add this directly into the method docstring: >> >>""" >>... >> >>:param self: the forest we establish trust to >>:param another_domain: a forest that establishes trust to 'self' >>:param cinfo: lsa_ForestTrustCollisionInfo structure that contain >> set of of lsa_ForestTrustCollisionRecord structures >>""" >> >>Additionally, the behavior specifed in previous comment can be added >>using :raises: stanza: >> >>""" >>:raises: errors.TrustTopologyConflictError if there are unresolvable >> namespace conflicts between trusted domains >>""" >> >>3.) >> >>rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to >>simplify code in 'update_ftinfo' like this: >> >>""" >>- res = self.clear_ftinfo_conflict(another_domain, cinfo) >>- if len(res[1]) != 0: >>- domains = [x.name.string for x in res[1]] >>- raise errors.TrustTopologyConflictError( >>- target=self.info['dns_domain'], >>- conflict=another_domain.info['dns_domain'], >>- domains=domains) >>- else: >>- raise errors.TrustTopologyConflictSolved( >>- target=self.info['dns_domain'], >>- conflict=another_domain.info['dns_domain']) >>+ self.clear_ftinfo_conflict(another_domain, cinfo) >>+ raise errors.TrustTopologyConflictSolved( >>+ target=self.info['dns_domain'], >>+ conflict=another_domain.info['dns_domain']) >>""" >> >>Patch 218: >> >>1.) >>typo in the commit message: >> >>""" >>... >>suffixes are forest-wide, there *are could be* user accounts in the >>... >>""" >> >>2.) >>A stupid question I know, but why do we need to replace empty string >>with None here? >> >>""" >> # with the forest, thus we have to use >>netr_DsRGetForestTrustInformation >>- domains = >>netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], '', 0) >>+ domains = >>netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], None, 0) >>""" >> > >Also I just noticed some pylint errors when doing build: > >Pylint is running, please wait ... >************* Module ipaserver.dcerpc >ipaserver/dcerpc.py:58: [E0401(import-error), ] Unable to import >'pysss_nss_idmap') >ipaserver/dcerpc.py:59: [E0401(import-error), ] Unable to import 'pysss') >ipaserver/dcerpc.py:1202: [E1305(too-many-format-args), >TrustDomainInstance.clear_ftinfo_conflict] Too many arguments for >format string) >ipaserver/dcerpc.py:1207: [E0602(undefined-variable), >TrustDomainInstance.clear_ftinfo_conflict] Undefined variable >'conflict_type') >Makefile:137: recipe for target 'pylint' failed > >You can probably ignore the first two since they may be caused by my >broken build environment. Right, conflict_type[rec.type] is a left-over I had originally to choose the type but since then decided to make two different error logging for in-forest and external to forest cases. Thanks. -- / Alexander Bokovoy From tkrizek at redhat.com Wed Aug 17 10:54:34 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Wed, 17 Aug 2016 12:54:34 +0200 Subject: [Freeipa-devel] [PATCH] 0106, 0107: webui: add warning that only one CA server exists In-Reply-To: References: Message-ID: <505e8da3-9a44-eeea-d2c4-e72ba65b2290@redhat.com> ACK, works for me. On 08/16/2016 10:43 AM, Pavel Vomacka wrote: > Hello, > > Please review attached patches which adds warning that only one CA > server is installed. > > https://fedorahosted.org/freeipa/ticket/5828 > > > -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Aug 17 10:58:25 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 17 Aug 2016 12:58:25 +0200 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: <20160817104107.yew3cbsfojeqkwr2@redhat.com> References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> <20160817104107.yew3cbsfojeqkwr2@redhat.com> Message-ID: On 17.8.2016 12:41, Alexander Bokovoy wrote: > On Wed, 17 Aug 2016, Martin Babinsky wrote: >> On 08/15/2016 06:06 PM, Alexander Bokovoy wrote: >>> On Mon, 15 Aug 2016, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> Attached are trust-related patches. >>>> >>>> 0207 is a pre-requisite. I did send it before, it is re-formatting of >>>> the ipaserver/dcerpc.py to be close to PEP8 requirements. >>>> >>>> 0218 is an automated trust topology conflict resolver for DNS namespace >>>> conflicts. Read the commit message for details, and also comments in the >>>> code. With this patch FreeIPA becomes more smart than Windows Server >>>> which doesn't have automated trust topology conflict resolution. ;) >>>> >>>> 0219 fixes issue of topology details leaking through external trust. The >>>> problem is only in presentation as we store more data than needed -- it >>>> is impossible to cross external trust boundary anyway as it is handled >>>> by AD DC side, but one important consequence is that we need to store >>>> UPN suffixes before we start storing information about child domains. >>>> Again, read the commit message. >>>> >>>> These patches also are on top of my previously sent patches 0215-0216. >>> Patches attached. >>> >>> >>> >> >> Hi Alexander, >> >> patch 207: LGTM, but I have a feeling that the patch should be linked to >> both #6021 and #6076 so that it is not lost during backports. >> >> patch 218: >> >> ipalib/errors.py: >> >> 1.) >> I'm not sure if TrustTopologyConflictError should inherit from >> InvocationError. The semantics of InvocationError implies that something was >> wrong when trying to invoke the command (a param failed to validate/convert, >> incorrect number of args, etc.), while this is more of an exception during >> command execution (no. and type of params was correct, command started to >> execute but encountered an error condition). Thus I think it should inherit >> from ExecutionError. CC'ing Jan for more thoughts on this. >> >> 2.) >> >> Why is TrustTopologyConflictSolved listed amogn public errors? Since it is >> used only in dcerpc.py to restart trust establishment after resolving >> conflicts, it should be a private exception in dcerpc.py for this purpose. >> >> 3.) >> Also please split the exception format string like this so that the line is >> not too long (there is not much we can do about doctest so leave that line >> as it is): >> >> @@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): >> """ >> >> errno = 3017 >> - format = _("Forest '%(forest)s' has existing trust to forest(s) >> %(domains)s which prevents a trust to '%(conflict)s'") >> + format = _("Forest '%(forest)s' has existing trust to forest(s) " >> + "%(domains)s which prevents a trust to '%(conflict)s'") >> >> Do not worry about gettext, it can handle it just fine, there are plenty of >> examples in server plugins, for example. >> >> >> ipaserver/dcerpc.py: >> >> 1.) >> >> I think that instead of returning result and raising >> TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' can >> raise this exception directly. You can have an empty list defined at the >> beginning instead of 'result list', append unresolvable conflicts to it and >> then at the end of the method check if it is non-empty and raise the exception. >> >> 2.) >> >> + # In the code below: >> + # self -- the forest we establish trust to >> + # another_domain -- a forest that establishes trust to 'self' >> + # cinfo -- lsa_ForestTrustCollisionInfo structure that contain >> + # set of of lsa_ForestTrustCollisionRecord structures >> I would add this directly into the method docstring: >> >> """ >> ... >> >> :param self: the forest we establish trust to >> :param another_domain: a forest that establishes trust to 'self' >> :param cinfo: lsa_ForestTrustCollisionInfo structure that contain >> set of of lsa_ForestTrustCollisionRecord structures >> """ >> >> Additionally, the behavior specifed in previous comment can be added using >> :raises: stanza: >> >> """ >> :raises: errors.TrustTopologyConflictError if there are unresolvable >> namespace conflicts between trusted domains >> """ >> >> 3.) >> >> rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to >> simplify code in 'update_ftinfo' like this: >> >> """ >> - res = self.clear_ftinfo_conflict(another_domain, cinfo) >> - if len(res[1]) != 0: >> - domains = [x.name.string for x in res[1]] >> - raise errors.TrustTopologyConflictError( >> - target=self.info['dns_domain'], >> - conflict=another_domain.info['dns_domain'], >> - domains=domains) >> - else: >> - raise errors.TrustTopologyConflictSolved( >> - target=self.info['dns_domain'], >> - conflict=another_domain.info['dns_domain']) >> + self.clear_ftinfo_conflict(another_domain, cinfo) >> + raise errors.TrustTopologyConflictSolved( >> + target=self.info['dns_domain'], >> + conflict=another_domain.info['dns_domain']) >> """ >> >> Patch 218: >> >> 1.) >> typo in the commit message: >> >> """ >> ... >> suffixes are forest-wide, there *are could be* user accounts in the >> ... >> """ >> >> 2.) >> A stupid question I know, but why do we need to replace empty string with >> None here? >> >> """ >> # with the forest, thus we have to use >> netr_DsRGetForestTrustInformation >> - domains = >> netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], '', 0) >> + domains = >> netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], None, 0) >> """ > I'm answering this one while working on the other fixes. > > netr_DsRGetForestTrustInformation() uses NULL to say a parameter is > missing, not empty string. It actually causes an issue if we don't do > that when asking a domain controller from a domain that is not a root > domain of the forest where we get currently undocumented error > NERR_ACFNotLoaded (0x000008b3). If non-NULL name is specified, AD domain > controller will perform proper operation only if it is a domain > controller from the forest root domain and the domain specified is > known. Obviously, a domain named '' cannot be known. This breaks external trust. > > Perhaps, this could be moved into a separate patch on its own. +1 You already wrote commit message for it to the e-mail so it is almost for free :-) This really should be documented somewhere. Petr^2 Spacek From mbabinsk at redhat.com Wed Aug 17 11:16:15 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 17 Aug 2016 13:16:15 +0200 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: <20160817104107.yew3cbsfojeqkwr2@redhat.com> References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> <20160817104107.yew3cbsfojeqkwr2@redhat.com> Message-ID: <05503944-aa21-7947-501a-e090b4d5cfa2@redhat.com> On 08/17/2016 12:41 PM, Alexander Bokovoy wrote: > On Wed, 17 Aug 2016, Martin Babinsky wrote: >> On 08/15/2016 06:06 PM, Alexander Bokovoy wrote: >>> On Mon, 15 Aug 2016, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> Attached are trust-related patches. >>>> >>>> 0207 is a pre-requisite. I did send it before, it is re-formatting of >>>> the ipaserver/dcerpc.py to be close to PEP8 requirements. >>>> >>>> 0218 is an automated trust topology conflict resolver for DNS namespace >>>> conflicts. Read the commit message for details, and also comments in >>>> the >>>> code. With this patch FreeIPA becomes more smart than Windows Server >>>> which doesn't have automated trust topology conflict resolution. ;) >>>> >>>> 0219 fixes issue of topology details leaking through external trust. >>>> The >>>> problem is only in presentation as we store more data than needed -- it >>>> is impossible to cross external trust boundary anyway as it is handled >>>> by AD DC side, but one important consequence is that we need to store >>>> UPN suffixes before we start storing information about child domains. >>>> Again, read the commit message. >>>> >>>> These patches also are on top of my previously sent patches 0215-0216. >>> Patches attached. >>> >>> >>> >> >> Hi Alexander, >> >> patch 207: LGTM, but I have a feeling that the patch should be linked >> to both #6021 and #6076 so that it is not lost during backports. >> >> patch 218: >> >> ipalib/errors.py: >> >> 1.) >> I'm not sure if TrustTopologyConflictError should inherit from >> InvocationError. The semantics of InvocationError implies that >> something was wrong when trying to invoke the command (a param failed >> to validate/convert, incorrect number of args, etc.), while this is >> more of an exception during command execution (no. and type of params >> was correct, command started to execute but encountered an error >> condition). Thus I think it should inherit from ExecutionError. CC'ing >> Jan for more thoughts on this. >> >> 2.) >> >> Why is TrustTopologyConflictSolved listed amogn public errors? Since >> it is used only in dcerpc.py to restart trust establishment after >> resolving conflicts, it should be a private exception in dcerpc.py for >> this purpose. >> >> 3.) >> Also please split the exception format string like this so that the >> line is not too long (there is not much we can do about doctest so >> leave that line as it is): >> >> @@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): >> """ >> >> errno = 3017 >> - format = _("Forest '%(forest)s' has existing trust to forest(s) >> %(domains)s which prevents a trust to '%(conflict)s'") >> + format = _("Forest '%(forest)s' has existing trust to forest(s) " >> + "%(domains)s which prevents a trust to '%(conflict)s'") >> >> Do not worry about gettext, it can handle it just fine, there are >> plenty of examples in server plugins, for example. >> >> >> ipaserver/dcerpc.py: >> >> 1.) >> >> I think that instead of returning result and raising >> TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' >> can raise this exception directly. You can have an empty list defined >> at the beginning instead of 'result list', append unresolvable >> conflicts to it and then at the end of the method check if it is >> non-empty and raise the exception. >> >> 2.) >> >> + # In the code below: >> + # self -- the forest we establish trust to >> + # another_domain -- a forest that establishes trust to 'self' >> + # cinfo -- lsa_ForestTrustCollisionInfo structure that contain >> + # set of of lsa_ForestTrustCollisionRecord structures >> I would add this directly into the method docstring: >> >> """ >> ... >> >> :param self: the forest we establish trust to >> :param another_domain: a forest that establishes trust to 'self' >> :param cinfo: lsa_ForestTrustCollisionInfo structure that contain >> set of of lsa_ForestTrustCollisionRecord structures >> """ >> >> Additionally, the behavior specifed in previous comment can be added >> using :raises: stanza: >> >> """ >> :raises: errors.TrustTopologyConflictError if there are unresolvable >> namespace conflicts between trusted domains >> """ >> >> 3.) >> >> rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to >> simplify code in 'update_ftinfo' like this: >> >> """ >> - res = self.clear_ftinfo_conflict(another_domain, cinfo) >> - if len(res[1]) != 0: >> - domains = [x.name.string for x in res[1]] >> - raise errors.TrustTopologyConflictError( >> - target=self.info['dns_domain'], >> - >> conflict=another_domain.info['dns_domain'], >> - domains=domains) >> - else: >> - raise errors.TrustTopologyConflictSolved( >> - target=self.info['dns_domain'], >> - >> conflict=another_domain.info['dns_domain']) >> + self.clear_ftinfo_conflict(another_domain, cinfo) >> + raise errors.TrustTopologyConflictSolved( >> + target=self.info['dns_domain'], >> + conflict=another_domain.info['dns_domain']) >> """ >> >> Patch 218: >> >> 1.) >> typo in the commit message: >> >> """ >> ... >> suffixes are forest-wide, there *are could be* user accounts in the >> ... >> """ >> >> 2.) >> A stupid question I know, but why do we need to replace empty string >> with None here? >> >> """ >> # with the forest, thus we have to use >> netr_DsRGetForestTrustInformation >> - domains = >> netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], '', 0) >> + domains = >> netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], None, 0) >> """ > I'm answering this one while working on the other fixes. > > netr_DsRGetForestTrustInformation() uses NULL to say a parameter is > missing, not empty string. It actually causes an issue if we don't do > that when asking a domain controller from a domain that is not a root > domain of the forest where we get currently undocumented error > NERR_ACFNotLoaded (0x000008b3). If non-NULL name is specified, AD domain > controller will perform proper operation only if it is a domain > controller from the forest root domain and the domain specified is > known. Obviously, a domain named '' cannot be known. This breaks > external trust. > > Perhaps, this could be moved into a separate patch on its own. > +1 for separate patch, thank you for your explanation. >> >> -- >> Martin^3 Babinsky > -- Martin^3 Babinsky From abokovoy at redhat.com Wed Aug 17 11:20:37 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Aug 2016 14:20:37 +0300 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> Message-ID: <20160817112037.phvkgo3zbw55gujk@redhat.com> On Wed, 17 Aug 2016, Martin Babinsky wrote: >Hi Alexander, > >patch 207: LGTM, but I have a feeling that the patch should be linked >to both #6021 and #6076 so that it is not lost during backports. > >patch 218: > >ipalib/errors.py: > >1.) >I'm not sure if TrustTopologyConflictError should inherit from >InvocationError. The semantics of InvocationError implies that >something was wrong when trying to invoke the command (a param failed >to validate/convert, incorrect number of args, etc.), while this is >more of an exception during command execution (no. and type of params >was correct, command started to execute but encountered an error >condition). Thus I think it should inherit from ExecutionError. CC'ing >Jan for more thoughts on this. Using ExecutionError would work to me too, as long as we display the error to a user. >Why is TrustTopologyConflictSolved listed amogn public errors? Since >it is used only in dcerpc.py to restart trust establishment after >resolving conflicts, it should be a private exception in dcerpc.py for >this purpose. I originally wanted to make it a warning -- i.e. if we fixed the conflict, return the result and show the warning that we did solve the conflict. After all, the code is modifying another trusted forest's topology on behalf of the user. I can move the error class to dcerpc.py >3.) >Also please split the exception format string like this so that the >line is not too long (there is not much we can do about doctest so >leave that line as it is): > >@@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): > """ > > errno = 3017 >- format = _("Forest '%(forest)s' has existing trust to forest(s) >%(domains)s which prevents a trust to '%(conflict)s'") >+ format = _("Forest '%(forest)s' has existing trust to forest(s) " >+ "%(domains)s which prevents a trust to '%(conflict)s'") > >Do not worry about gettext, it can handle it just fine, there are >plenty of examples in server plugins, for example. Done. >ipaserver/dcerpc.py: > >1.) > >I think that instead of returning result and raising >TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' >can raise this exception directly. You can have an empty list defined >at the beginning instead of 'result list', append unresolvable >conflicts to it and then at the end of the method check if it is >non-empty and raise the exception. Good suggestion, fixed. > >2.) > >+ # In the code below: >+ # self -- the forest we establish trust to >+ # another_domain -- a forest that establishes trust to 'self' >+ # cinfo -- lsa_ForestTrustCollisionInfo structure that contain >+ # set of of lsa_ForestTrustCollisionRecord structures >I would add this directly into the method docstring: > >""" >... > >:param self: the forest we establish trust to >:param another_domain: a forest that establishes trust to 'self' >:param cinfo: lsa_ForestTrustCollisionInfo structure that contain > set of of lsa_ForestTrustCollisionRecord structures >""" Added. >Additionally, the behavior specifed in previous comment can be added >using :raises: stanza: > >""" >:raises: errors.TrustTopologyConflictError if there are unresolvable > namespace conflicts between trusted domains >""" Added. > >3.) > >rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to >simplify code in 'update_ftinfo' like this: > >""" >- res = self.clear_ftinfo_conflict(another_domain, cinfo) >- if len(res[1]) != 0: >- domains = [x.name.string for x in res[1]] >- raise errors.TrustTopologyConflictError( >- target=self.info['dns_domain'], >- conflict=another_domain.info['dns_domain'], >- domains=domains) >- else: >- raise errors.TrustTopologyConflictSolved( >- target=self.info['dns_domain'], >- conflict=another_domain.info['dns_domain']) >+ self.clear_ftinfo_conflict(another_domain, cinfo) >+ raise errors.TrustTopologyConflictSolved( >+ target=self.info['dns_domain'], >+ conflict=another_domain.info['dns_domain']) >""" done. > >Patch 218: > >1.) >typo in the commit message: > >""" >... >suffixes are forest-wide, there *are could be* user accounts in the >... >""" Fixed. Updated patches attached. -- / Alexander Bokovoy -------------- next part -------------- From 4c6e1c5ce1eddd70aac5cf97075af3cf15bb951a Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 15 Aug 2016 18:14:00 +0300 Subject: [PATCH 09/10] trust: automatically resolve DNS trust conflicts for triangle trusts For configuration where: - AD example.com trusts IPA at ipa.example.com - AD example.org trusts AD example.com - a trust is tried to be established between ipa.example.com and example.org, there will be a trust topology conflict detected by example.org domain controller because ipa.example.com DNS namespace overlaps with example.com DNS namespace. This type of trust topology conflict is documented in MS-ADTS 6.1.6.9.3.2 "Building Well-Formed msDS-TrustForestTrustInfo Message". A similar conflict can arise for SID and NetBIOS namespaces. However, unlike SID and NetBIOS namespaces, we can solve DNS namespace conflict automatically if there are administrative credentials for example.org available. A manual sequence to solve the DNS namespace conflict is described in https://msdn.microsoft.com/it-it/library/cc786254%28v=ws.10%29.aspx. This sequence boils down to the following steps: 1. As an administrator of the example.org, you need to add an exclusion entry for ipa.example.com in the properties of the trust to example.com 2. Establish trust between ipa.example.com and example.org It is important to add the exclusion entry before step 4 or there will be conflict recorded which cannot be cleared easily right now due to a combination of bugs in both IPA and Active Directory. This patchset implements automated solution for the case when we have access to the example.org's administrator credentials: 1. Attempt to establish trust and update trust topology information. 2. If trust topology conflict is detected as result of (1): 2.1. Fetch trust topology infromation for the conflicting forest trust 2.2. Add exclusion entry to our domain to the trust topology obtained in (2.1) 2.3. Update trust topology for the conflicting forest trust 3. Re-establish trust between ipa.example.com and example.org We cannot do the same for shared secret trust and for external trust, though: 1. For shared secret trust we don't have administrative credentials in the forest reporting the conflict 2. For the external trust we cannot set topology information due to MS-LSAD 3.1.4.7.16 because external trust is non-transitive by definition and thus setting topology information will fail. To test this logic one can use two Samba AD forests with FreeIPA using a sub-domain of one of them. Fixes: https://fedorahosted.org/freeipa/ticket/6076 --- ipalib/errors.py | 29 ++++++- ipaserver/dcerpc.py | 220 +++++++++++++++++++++++++++++++++++++++++++++------- 2 files changed, 220 insertions(+), 29 deletions(-) diff --git a/ipalib/errors.py b/ipalib/errors.py index 7b4f15d..4cc4455 100644 --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -866,7 +866,6 @@ class NotAForestRootError(InvocationError): errno = 3016 format = _("Domain '%(domain)s' is not a root domain for forest '%(forest)s'") - ############################################################################## # 4000 - 4999: Execution errors @@ -1908,6 +1907,34 @@ class DNSResolverError(DNSError): errno = 4401 format = _('%(exception)s') +class TrustError(ExecutionError): + """ + **4500** Base class for trust execution errors (*4500 - 4599*). + These are typically instantiated when there is an error in establishing or + modifying a trust to another forest. + """ + + errno = 4500 + +class TrustTopologyConflictError(TrustError): + """ + **4501** Raised when an attempt to establish trust fails with a topology + conflict against another forest the target forest trusts + + For example: + + >>> raise TrustTopologyConflictError(forest='example.test', + conflict='my.ad.test', + domains=['ad.test']) + Traceback (most recent call last): + ... + TrustTopologyConflictError: Forest 'example.test' has existing trust to forest(s) ['ad.test'] which prevents a trust to 'my.ad.test' + """ + + errno = 4501 + format = _("Forest '%(forest)s' has existing trust to forest(s) " + "%(domains)s which prevents a trust to '%(conflict)s'") + ############################################################################## # 5000 - 5999: Generic errors diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 19be6bf..da70ac3 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -1,7 +1,7 @@ # Authors: # Alexander Bokovoy # -# Copyright (C) 2011 Red Hat +# Copyright (C) 2011-2016 Red Hat # see file 'COPYING' for use and warranty information # # Portions (C) Andrew Tridgell, Andrew Bartlett @@ -140,6 +140,15 @@ pysss_type_key_translation_dict = { pysss_nss_idmap.ID_BOTH: 'both', } +class TrustTopologyConflictSolved(errors.TrustError): + """ + Internal trust error: raised when previously detected + trust topology conflict is automatically solved. + + No separate errno is assigned as this error should + not be visible outside the dcerpc.py code. + """ + pass def assess_dcerpc_exception(num=None, message=None): """ @@ -1087,34 +1096,165 @@ class TrustDomainInstance(object): info.entries = ftinfo_records return info + def clear_ftinfo_conflict(self, another_domain, cinfo): + """ + Attempt to clean up the forest trust collisions + + :param self: the forest we establish trust to + :param another_domain: a forest that establishes trust to 'self' + :param cinfo: lsa_ForestTrustCollisionInfo structure that contain + set of of lsa_ForestTrustCollisionRecord structures + :raises: TrustTopologyConflictSolved, TrustTopologyConflictError + + This code tries to perform intelligent job of going + over individual collisions and making exclusion entries + for affected IPA namespaces. + + There are three possible conflict configurations: + - conflict of DNS namespace (TLN conflict, LSA_TLN_DISABLED_CONFLICT) + - conflict of SID namespace (LSA_SID_DISABLED_CONFLICT) + - conflict of NetBIOS namespace (LSA_NB_DISABLED_CONFLICT) + + we only can handle TLN conflicts because (a) excluding SID namespace + is not possible and (b) excluding NetBIOS namespace not possible. + These two types of conflicts should result in trust-add CLI error + + These conflicts can come from external source (another forest) or + from internal source (another domain in the same forest). We only + can fix the problems with another forest. + + To resolve TLN conflict we need to do following: + 1. Retrieve forest trust information for the forest we conflict on + 2. Add an exclusion entry for IPA DNS namespace to it + 3. Set forest trust information for the forest we conflict on + 4. Re-try establishing trust to the original forest + + This all can only be done under privileges of Active Directory admin + that can change forest trusts. If we cannot have those privileges, + the work has to be done manually in the Windows UI for + 'Active Directory Domains and Trusts' by the administrator of the + original forest. + """ + + # List of entries for unsolved conflicts + result = [] + + trust_timestamp = long(time.time()*1e7+116444736000000000) + + # Collision information contains entries for specific trusted domains + # we collide with. Look into TLN collisions and add a TLN exclusion + # entry to the specific domain trust. + root_logger.error("Attempt to solve forest trust topology conflicts") + for rec in cinfo.entries: + if rec.type == lsa.LSA_FOREST_TRUST_COLLISION_TDO: + dominfo = self._pipe.lsaRQueryForestTrustInformation( + self._policy_handle, + rec.name, + lsa.LSA_FOREST_TRUST_DOMAIN_INFO) + + # Oops, we were unable to retrieve trust topology for this + # trusted domain (forest). + if not dominfo: + result.append(rec) + root_logger.error("Unable to resolve conflict for " + "DNS domain %s in the forest %s " + "for domain trust %s. Trust cannot " + "be established unless this conflict " + "is fixed manually." + % (another_domain.info['dns_domain'], + self.info['dns_domain'], + rec.name.string)) + continue + + # Copy over the entries, extend with TLN exclusion + entries = [] + for e in dominfo.entries: + e1 = lsa.ForestTrustRecord() + e1.type = e.type + e1.flags = e.flags + e1.time = e.time + e1.forest_trust_data = e.forest_trust_data + entries.append(e1) + + # Create TLN exclusion record + record = lsa.ForestTrustRecord() + record.type = lsa.LSA_FOREST_TRUST_TOP_LEVEL_NAME_EX + record.flags = 0 + record.time = trust_timestamp + record.forest_trust_data.string = \ + another_domain.info['dns_domain'] + entries.append(record) + + fti = lsa.ForestTrustInformation() + fti.count = len(entries) + fti.entries = entries + + # Update the forest trust information now + ldname = lsa.StringLarge() + ldname.string = rec.name.string + cninfo = self._pipe.lsaRSetForestTrustInformation( + self._policy_handle, + ldname, + lsa.LSA_FOREST_TRUST_DOMAIN_INFO, + fti, 0) + if cninfo: + result.append(rec) + root_logger.error("When defining exception for DNS " + "domain %s in forest %s for " + "trusted forest %s, " + "got collision info back:\n%s" + % (another_domain.info['dns_domain'], + self.info['dns_domain'], + rec.name.string, + ndr_print(cninfo))) + else: + result.append(rec) + root_logger.error("Unable to resolve conflict for " + "DNS domain %s in the forest %s " + "for in-forest domain %s. Trust cannot " + "be established unless this conflict " + "is fixed manually." + % (another_domain.info['dns_domain'], + self.info['dns_domain'], + rec.name.string)) + + if len(result) == 0: + root_logger.error("Successfully solved all conflicts") + raise TrustTopologyConflictSolved() + + # Otherwise, raise TrustTopologyConflictError() exception + domains = [x.name.string for x in result] + raise errors.TrustTopologyConflictError( + target=self.info['dns_domain'], + conflict=another_domain.info['dns_domain'], + domains=domains) + + + def update_ftinfo(self, another_domain): """ Updates forest trust information in this forest corresponding to the another domain's information. """ - try: - if another_domain.ftinfo_records: - ftinfo = self.generate_ftinfo(another_domain) - # Set forest trust information -- we do it only against AD DC as - # smbd already has the information about itself - ldname = lsa.StringLarge() - ldname.string = another_domain.info['dns_domain'] - ftlevel = lsa.LSA_FOREST_TRUST_DOMAIN_INFO - # RSetForestTrustInformation returns collision information - # for trust topology - cinfo = self._pipe.lsaRSetForestTrustInformation( - self._policy_handle, - ldname, - ftlevel, - ftinfo, 0) - if cinfo: - root_logger.error("When setting forest trust information, " - "got collision info back:\n%s" - % (ndr_print(cinfo))) - except RuntimeError as e: - # We can ignore the error here -- - # setting up name suffix routes may fail - pass + if another_domain.ftinfo_records: + ftinfo = self.generate_ftinfo(another_domain) + # Set forest trust information -- we do it only against AD DC as + # smbd already has the information about itself + ldname = lsa.StringLarge() + ldname.string = another_domain.info['dns_domain'] + ftlevel = lsa.LSA_FOREST_TRUST_DOMAIN_INFO + # RSetForestTrustInformation returns collision information + # for trust topology + cinfo = self._pipe.lsaRSetForestTrustInformation( + self._policy_handle, + ldname, + ftlevel, + ftinfo, 0) + if cinfo: + root_logger.error("When setting forest trust information, " + "got collision info back:\n%s" + % (ndr_print(cinfo))) + self.clear_ftinfo_conflict(another_domain, cinfo) def establish_trust(self, another_domain, trustdom_secret, trust_type='bidirectional', trust_external=False): @@ -1207,7 +1347,19 @@ class TrustDomainInstance(object): root_logger.error( 'unable to set trust transitivity status: %s' % (str(e))) - if self.info['is_pdc'] or trust_external: + # Updating forest trust info may fail + # If it failed due to topology conflict, it may be fixed automatically + # update_ftinfo() will through exceptions in that case + # Note that MS-LSAD 3.1.4.7.16 says: + # ------------------------- + # The server MUST also make sure that the trust attributes associated + # with the trusted domain object referenced by the TrustedDomainName + # parameter has the TRUST_ATTRIBUTE_FOREST_TRANSITIVE set. + # If the attribute is not present, the server MUST return + # STATUS_INVALID_PARAMETER. + # ------------------------- + # Thus, we must not update forest trust info for the external trust + if self.info['is_pdc'] and not trust_external: self.update_ftinfo(another_domain) def verify_trust(self, another_domain): @@ -1509,9 +1661,21 @@ class TrustDomainJoins(object): if not self.remote_domain.read_only: trustdom_pass = samba.generate_random_password(128, 128) self.get_realmdomains() - self.remote_domain.establish_trust(self.local_domain, - trustdom_pass, - trust_type, trust_external) + + # Establishing trust may throw an exception for topology + # conflict. If it was solved, re-establish the trust again + # Otherwise let the CLI to display a message about the conflict + try: + self.remote_domain.establish_trust(self.local_domain, + trustdom_pass, + trust_type, trust_external) + except TrustTopologyConflictSolved as e: + # we solved topology conflict, retry again + self.remote_domain.establish_trust(self.local_domain, + trustdom_pass, + trust_type, trust_external) + + # For local domain we don't set topology information self.local_domain.establish_trust(self.remote_domain, trustdom_pass, trust_type, trust_external) -- 2.7.4 -------------- next part -------------- From e56bba9bc6718c7b1cea88a75a9d7633d2cc7da1 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 15 Aug 2016 18:32:25 +0300 Subject: [PATCH 10/10] trust: make sure external trust topology is correctly rendered When external trust is established, it is by definition is non-transitive: it is not possible to obtain Kerberos tickets to any service outside the trusted domain. Reflect this reality by only accepting UPN suffixes from the external trust -- since the trusted domain is a part of another forest and UPN suffixes are forest-wide, there could be user accounts in the trusted domain that use forest-wide UPN suffix but it will be impossible to reach the forest root via the externally trusted domain. Also, an argument to netr_DsRGetForestTrustInformation() has to be either forest root domain name or None (NULL). Otherwise we'll get an error as explained in MS-NRPC 3.5.4.7.5. https://fedorahosted.org/freeipa/ticket/6021 --- ipaserver/dcerpc.py | 2 +- ipaserver/plugins/trust.py | 28 +++++++++++++++++----------- 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index da70ac3..d13cdf0 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -1449,7 +1449,7 @@ def fetch_domains(api, mydomain, trustdomain, creds=None, server=None): # Older FreeIPA versions used netr_DsrEnumerateDomainTrusts call # but it doesn't provide information about non-domain UPNs associated # with the forest, thus we have to use netr_DsRGetForestTrustInformation - domains = netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], '', 0) + domains = netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], None, 0) return domains domains = None diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py index f90d9c1..b9d9b12 100644 --- a/ipaserver/plugins/trust.py +++ b/ipaserver/plugins/trust.py @@ -1663,6 +1663,23 @@ def add_new_domains_from_trust(myapi, trustinstance, trust_entry, domains, **opt for x, y in six.iteritems(domains['suffixes']) if x not in domains['domains']) + try: + dn = myapi.Object.trust.get_dn(trust_name, trust_type=u'ad') + ldap = myapi.Backend.ldap2 + entry = ldap.get_entry(dn) + tlns = entry.get('ipantadditionalsuffixes', []) + tlns.extend(x for x in suffixes if x not in tlns) + entry['ipantadditionalsuffixes'] = tlns + ldap.update_entry(entry) + except errors.EmptyModlist: + pass + + is_nontransitive = int(trust_entry.get('ipanttrustattributes', + [0])[0]) & LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE + + if is_nontransitive: + return result + for dom in six.itervalues(domains['domains']): dom['trust_type'] = u'ad' try: @@ -1690,17 +1707,6 @@ def add_new_domains_from_trust(myapi, trustinstance, trust_entry, domains, **opt # Ignore updating duplicate entries pass - try: - dn = myapi.Object.trust.get_dn(trust_name, trust_type=u'ad') - ldap = myapi.Backend.ldap2 - entry = ldap.get_entry(dn) - tlns = entry.get('ipantadditionalsuffixes', []) - tlns.extend(x for x in suffixes if x not in tlns) - entry['ipantadditionalsuffixes'] = tlns - ldap.update_entry(entry) - except errors.EmptyModlist: - pass - return result -- 2.7.4 From dkupka at redhat.com Wed Aug 17 11:21:31 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 17 Aug 2016 13:21:31 +0200 Subject: [Freeipa-devel] [PATCH 0112-7] Speeding up cli help In-Reply-To: References: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> <01ff40a4-b964-4f78-33dd-f1c92c490fdd@redhat.com> <29310e45-fc18-52fc-1686-651bb42480c9@redhat.com> <547fcaaa-c86c-f547-c049-2de82df78de8@redhat.com> Message-ID: <1ff6376d-e47b-cceb-0661-c66f2e3e4133@redhat.com> On 08/08/16 13:26, Jan Cholasta wrote: > On 4.8.2016 16:32, David Kupka wrote: >> On 03/08/16 16:33, Jan Cholasta wrote: >>> On 3.8.2016 16:23, David Kupka wrote: >>>> On 21/07/16 10:12, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 20.7.2016 14:32, David Kupka wrote: >>>>>> On 15/07/16 12:53, David Kupka wrote: >>>>>>> Hello! >>>>>>> >>>>>>> After Honza introduced thin client that builds plugins and commands >>>>>>> dynamically from schema client became much slower. This is only >>>>>>> logical, >>>>>>> instead of importing a module client now must fetch the schema from >>>>>>> server, parse it and instantiate the commands using the data. >>>>>>> >>>>>>> First step to speed it up was addition of schema cache to client. >>>>>>> That >>>>>>> removed the RTT and download time of fetching schema every time. >>>>>>> >>>>>>> Now the most time consuming task became displaying help for lists of >>>>>>> topics and command and displaying individual topics. This is simply >>>>>>> because of the need to instantiate all the commands to find the >>>>>>> relations between topics and commands. >>>>>>> >>>>>>> All the necessary bits for server commands and topics are already in >>>>>>> the >>>>>>> schema cache so we can skip this part and generate help from it, >>>>>>> right? >>>>>>> Not so fast! >>>>>>> >>>>>>> There are client plugins with commands and topics. So we can >>>>>>> generate >>>>>>> basic bits (list of all topics, list of all commands, list of >>>>>>> commands >>>>>>> for each topic) from schema and store it in cache. Then we need >>>>>>> to go >>>>>>> through all client plugins and get similar bits for client plugins. >>>>>>> Then >>>>>>> we can merge and print. >>>>>>> >>>>>>> Still the client response is not as fast as before and I this it >>>>>>> even >>>>>>> can't be. Also first time you display particular topic or list takes >>>>>>> longer because it must be freshly generated and stored in cache for >>>>>>> next >>>>>>> use. And this is what the attached patches do. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/6048 >>>>>> >>>>>> Reimplemented so there is no need to distinguish client plugins and >>>>>> remote plugins. >>>>>> The main idea of this approach is to avoid creating instances of the >>>>>> commands just to get the information about topic, name and summary >>>>>> needed for displaying help. Instead class properties are used to >>>>>> access >>>>>> the information directly in schema. >>>>> >>>>> Patch 0112: >>>>> >>>>> I think this would better be done in Schema.read_namespace_member, >>>>> because Schema is where all the state is. >>>>> >>>>> (BTW does _SchemaNameSpace.__getitem__ raise KeyError for non-existent >>>>> keys? It looks like it doesn't.) >>>>> >>>>> >>>>> Patch 0113: >>>>> >>>>> How about setting _schema_cached to False in Schema.__init__() rather >>>>> that getattr()-ing it in _ensure_cached()? >>>>> >>>>> >>>>> Patch 0116: >>>>> >>>>> ClientCommand.doc should be a class property as well, otherwise >>>>> .summary >>>>> won't work on it correctly. >>>>> >>>>> _SchemaCommand.doc should not be a property, as it's not needed for >>>>> .summary to work on it correctly. >>>>> >>>>> >>>>> Otherwise works fine for me. >>>>> >>>>> Honza >>>>> >>>> >>>> Updated patches attached. >>> >>> Thanks, ACK. >>> >>> Pushed to master: 229e2a1ed9ea9877cb5e879fadd99f9040f77c96 >>> >> >> I've made and reviewer overlooked some errors. Attached patches fix them. > > Shame on me. > > Anyway, > > 1) When schema() raises SchemaUpToDate, the current code explodes: > > ipa: ERROR: KeyError: 'fingerprint' > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1348, in run > api.finalize() > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 707, > in finalize > self.__do_if_not_done('load_plugins') > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 422, > in __do_if_not_done > getattr(self, name)() > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 585, > in load_plugins > for package in self.packages: > File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 919, > in packages > ipaclient.remote_plugins.get_package(self), > File > "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", > line 92, in get_package > plugins = schema.get_package(api, server_info, client) > File > "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", > line 558, in get_package > fingerprint = str(schema['fingerprint']) > File > "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", > line 483, in __getitem__ > return self._dict[key] > KeyError: 'fingerprint' > > > 2) We read server info every time get_package() is called. It should be > cache similarly to how the schema is cached in the api object. > > > 3) Some of the commands are still fully initialized during "ipa help > commands". > > > Honza > Updated patches attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0119.1-schema-cache-Do-not-reset-ServerInfo-dirty-flag.patch Type: text/x-patch Size: 1133 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0120.1-schema-cache-Do-not-read-fingerprint-and-format-from.patch Type: text/x-patch Size: 3405 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0121.1-Access-data-for-help-separately.patch Type: text/x-patch Size: 4475 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0122.1-frontent-Add-summary-class-property-to-CommandOverri.patch Type: text/x-patch Size: 958 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0123.1-schema-cache-Read-server-info-only-once.patch Type: text/x-patch Size: 2102 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0124.1-schema-cache-Store-API-schema-cache-in-memory.patch Type: text/x-patch Size: 4167 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0125.1-client-Do-not-create-instance-just-to-check-isinstan.patch Type: text/x-patch Size: 3626 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0126.1-schema-cache-Read-schema-instead-of-rewriting-it-whe.patch Type: text/x-patch Size: 3604 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0127.1-schema-check-Check-current-client-language-against-c.patch Type: text/x-patch Size: 1834 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0128.1-compat-Fix-ping-command-call.patch Type: text/x-patch Size: 1088 bytes Desc: not available URL: From abokovoy at redhat.com Wed Aug 17 11:22:16 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Aug 2016 14:22:16 +0300 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> <20160817104107.yew3cbsfojeqkwr2@redhat.com> Message-ID: <20160817112216.dt5zf2cmfgnenkik@redhat.com> On Wed, 17 Aug 2016, Petr Spacek wrote: >On 17.8.2016 12:41, Alexander Bokovoy wrote: >> On Wed, 17 Aug 2016, Martin Babinsky wrote: >>> On 08/15/2016 06:06 PM, Alexander Bokovoy wrote: >>>> On Mon, 15 Aug 2016, Alexander Bokovoy wrote: >>>>> Hi! >>>>> >>>>> Attached are trust-related patches. >>>>> >>>>> 0207 is a pre-requisite. I did send it before, it is re-formatting of >>>>> the ipaserver/dcerpc.py to be close to PEP8 requirements. >>>>> >>>>> 0218 is an automated trust topology conflict resolver for DNS namespace >>>>> conflicts. Read the commit message for details, and also comments in the >>>>> code. With this patch FreeIPA becomes more smart than Windows Server >>>>> which doesn't have automated trust topology conflict resolution. ;) >>>>> >>>>> 0219 fixes issue of topology details leaking through external trust. The >>>>> problem is only in presentation as we store more data than needed -- it >>>>> is impossible to cross external trust boundary anyway as it is handled >>>>> by AD DC side, but one important consequence is that we need to store >>>>> UPN suffixes before we start storing information about child domains. >>>>> Again, read the commit message. >>>>> >>>>> These patches also are on top of my previously sent patches 0215-0216. >>>> Patches attached. >>>> >>>> >>>> >>> >>> Hi Alexander, >>> >>> patch 207: LGTM, but I have a feeling that the patch should be linked to >>> both #6021 and #6076 so that it is not lost during backports. >>> >>> patch 218: >>> >>> ipalib/errors.py: >>> >>> 1.) >>> I'm not sure if TrustTopologyConflictError should inherit from >>> InvocationError. The semantics of InvocationError implies that something was >>> wrong when trying to invoke the command (a param failed to validate/convert, >>> incorrect number of args, etc.), while this is more of an exception during >>> command execution (no. and type of params was correct, command started to >>> execute but encountered an error condition). Thus I think it should inherit >>> from ExecutionError. CC'ing Jan for more thoughts on this. >>> >>> 2.) >>> >>> Why is TrustTopologyConflictSolved listed amogn public errors? Since it is >>> used only in dcerpc.py to restart trust establishment after resolving >>> conflicts, it should be a private exception in dcerpc.py for this purpose. >>> >>> 3.) >>> Also please split the exception format string like this so that the line is >>> not too long (there is not much we can do about doctest so leave that line >>> as it is): >>> >>> @@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): >>> """ >>> >>> errno = 3017 >>> - format = _("Forest '%(forest)s' has existing trust to forest(s) >>> %(domains)s which prevents a trust to '%(conflict)s'") >>> + format = _("Forest '%(forest)s' has existing trust to forest(s) " >>> + "%(domains)s which prevents a trust to '%(conflict)s'") >>> >>> Do not worry about gettext, it can handle it just fine, there are plenty of >>> examples in server plugins, for example. >>> >>> >>> ipaserver/dcerpc.py: >>> >>> 1.) >>> >>> I think that instead of returning result and raising >>> TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' can >>> raise this exception directly. You can have an empty list defined at the >>> beginning instead of 'result list', append unresolvable conflicts to it and >>> then at the end of the method check if it is non-empty and raise the exception. >>> >>> 2.) >>> >>> + # In the code below: >>> + # self -- the forest we establish trust to >>> + # another_domain -- a forest that establishes trust to 'self' >>> + # cinfo -- lsa_ForestTrustCollisionInfo structure that contain >>> + # set of of lsa_ForestTrustCollisionRecord structures >>> I would add this directly into the method docstring: >>> >>> """ >>> ... >>> >>> :param self: the forest we establish trust to >>> :param another_domain: a forest that establishes trust to 'self' >>> :param cinfo: lsa_ForestTrustCollisionInfo structure that contain >>> set of of lsa_ForestTrustCollisionRecord structures >>> """ >>> >>> Additionally, the behavior specifed in previous comment can be added using >>> :raises: stanza: >>> >>> """ >>> :raises: errors.TrustTopologyConflictError if there are unresolvable >>> namespace conflicts between trusted domains >>> """ >>> >>> 3.) >>> >>> rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to >>> simplify code in 'update_ftinfo' like this: >>> >>> """ >>> - res = self.clear_ftinfo_conflict(another_domain, cinfo) >>> - if len(res[1]) != 0: >>> - domains = [x.name.string for x in res[1]] >>> - raise errors.TrustTopologyConflictError( >>> - target=self.info['dns_domain'], >>> - conflict=another_domain.info['dns_domain'], >>> - domains=domains) >>> - else: >>> - raise errors.TrustTopologyConflictSolved( >>> - target=self.info['dns_domain'], >>> - conflict=another_domain.info['dns_domain']) >>> + self.clear_ftinfo_conflict(another_domain, cinfo) >>> + raise errors.TrustTopologyConflictSolved( >>> + target=self.info['dns_domain'], >>> + conflict=another_domain.info['dns_domain']) >>> """ >>> >>> Patch 218: >>> >>> 1.) >>> typo in the commit message: >>> >>> """ >>> ... >>> suffixes are forest-wide, there *are could be* user accounts in the >>> ... >>> """ >>> >>> 2.) >>> A stupid question I know, but why do we need to replace empty string with >>> None here? >>> >>> """ >>> # with the forest, thus we have to use >>> netr_DsRGetForestTrustInformation >>> - domains = >>> netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], '', 0) >>> + domains = >>> netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], None, 0) >>> """ >> I'm answering this one while working on the other fixes. >> >> netr_DsRGetForestTrustInformation() uses NULL to say a parameter is >> missing, not empty string. It actually causes an issue if we don't do >> that when asking a domain controller from a domain that is not a root >> domain of the forest where we get currently undocumented error >> NERR_ACFNotLoaded (0x000008b3). If non-NULL name is specified, AD domain >> controller will perform proper operation only if it is a domain >> controller from the forest root domain and the domain specified is >> known. Obviously, a domain named '' cannot be known. This breaks external trust. >> >> Perhaps, this could be moved into a separate patch on its own. >+1 > >You already wrote commit message for it to the e-mail so it is almost for free >:-) This really should be documented somewhere. Uhm, no. The separate patch is there -- that change of '' to None is part of the proper patch 0219. When I wrote the message above I was thinking it is actually a part of 0218. Silly me. So no changes, I did add a small sentence to the commit message in new version of 0219 which refers to the MS-NRPC spec. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Aug 17 11:22:41 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Aug 2016 14:22:41 +0300 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: <05503944-aa21-7947-501a-e090b4d5cfa2@redhat.com> References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> <20160817104107.yew3cbsfojeqkwr2@redhat.com> <05503944-aa21-7947-501a-e090b4d5cfa2@redhat.com> Message-ID: <20160817112241.gwdlhgdruvz4oz4t@redhat.com> On Wed, 17 Aug 2016, Martin Babinsky wrote: >On 08/17/2016 12:41 PM, Alexander Bokovoy wrote: >>On Wed, 17 Aug 2016, Martin Babinsky wrote: >>>On 08/15/2016 06:06 PM, Alexander Bokovoy wrote: >>>>On Mon, 15 Aug 2016, Alexander Bokovoy wrote: >>>>>Hi! >>>>> >>>>>Attached are trust-related patches. >>>>> >>>>>0207 is a pre-requisite. I did send it before, it is re-formatting of >>>>>the ipaserver/dcerpc.py to be close to PEP8 requirements. >>>>> >>>>>0218 is an automated trust topology conflict resolver for DNS namespace >>>>>conflicts. Read the commit message for details, and also comments in >>>>>the >>>>>code. With this patch FreeIPA becomes more smart than Windows Server >>>>>which doesn't have automated trust topology conflict resolution. ;) >>>>> >>>>>0219 fixes issue of topology details leaking through external trust. >>>>>The >>>>>problem is only in presentation as we store more data than needed -- it >>>>>is impossible to cross external trust boundary anyway as it is handled >>>>>by AD DC side, but one important consequence is that we need to store >>>>>UPN suffixes before we start storing information about child domains. >>>>>Again, read the commit message. >>>>> >>>>>These patches also are on top of my previously sent patches 0215-0216. >>>>Patches attached. >>>> >>>> >>>> >>> >>>Hi Alexander, >>> >>>patch 207: LGTM, but I have a feeling that the patch should be linked >>>to both #6021 and #6076 so that it is not lost during backports. >>> >>>patch 218: >>> >>>ipalib/errors.py: >>> >>>1.) >>>I'm not sure if TrustTopologyConflictError should inherit from >>>InvocationError. The semantics of InvocationError implies that >>>something was wrong when trying to invoke the command (a param failed >>>to validate/convert, incorrect number of args, etc.), while this is >>>more of an exception during command execution (no. and type of params >>>was correct, command started to execute but encountered an error >>>condition). Thus I think it should inherit from ExecutionError. CC'ing >>>Jan for more thoughts on this. >>> >>>2.) >>> >>>Why is TrustTopologyConflictSolved listed amogn public errors? Since >>>it is used only in dcerpc.py to restart trust establishment after >>>resolving conflicts, it should be a private exception in dcerpc.py for >>>this purpose. >>> >>>3.) >>>Also please split the exception format string like this so that the >>>line is not too long (there is not much we can do about doctest so >>>leave that line as it is): >>> >>>@@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): >>> """ >>> >>> errno = 3017 >>>- format = _("Forest '%(forest)s' has existing trust to forest(s) >>>%(domains)s which prevents a trust to '%(conflict)s'") >>>+ format = _("Forest '%(forest)s' has existing trust to forest(s) " >>>+ "%(domains)s which prevents a trust to '%(conflict)s'") >>> >>>Do not worry about gettext, it can handle it just fine, there are >>>plenty of examples in server plugins, for example. >>> >>> >>>ipaserver/dcerpc.py: >>> >>>1.) >>> >>>I think that instead of returning result and raising >>>TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' >>>can raise this exception directly. You can have an empty list defined >>>at the beginning instead of 'result list', append unresolvable >>>conflicts to it and then at the end of the method check if it is >>>non-empty and raise the exception. >>> >>>2.) >>> >>>+ # In the code below: >>>+ # self -- the forest we establish trust to >>>+ # another_domain -- a forest that establishes trust to 'self' >>>+ # cinfo -- lsa_ForestTrustCollisionInfo structure that contain >>>+ # set of of lsa_ForestTrustCollisionRecord structures >>>I would add this directly into the method docstring: >>> >>>""" >>>... >>> >>>:param self: the forest we establish trust to >>>:param another_domain: a forest that establishes trust to 'self' >>>:param cinfo: lsa_ForestTrustCollisionInfo structure that contain >>> set of of lsa_ForestTrustCollisionRecord structures >>>""" >>> >>>Additionally, the behavior specifed in previous comment can be added >>>using :raises: stanza: >>> >>>""" >>>:raises: errors.TrustTopologyConflictError if there are unresolvable >>> namespace conflicts between trusted domains >>>""" >>> >>>3.) >>> >>>rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to >>>simplify code in 'update_ftinfo' like this: >>> >>>""" >>>- res = self.clear_ftinfo_conflict(another_domain, cinfo) >>>- if len(res[1]) != 0: >>>- domains = [x.name.string for x in res[1]] >>>- raise errors.TrustTopologyConflictError( >>>- target=self.info['dns_domain'], >>>- >>>conflict=another_domain.info['dns_domain'], >>>- domains=domains) >>>- else: >>>- raise errors.TrustTopologyConflictSolved( >>>- target=self.info['dns_domain'], >>>- >>>conflict=another_domain.info['dns_domain']) >>>+ self.clear_ftinfo_conflict(another_domain, cinfo) >>>+ raise errors.TrustTopologyConflictSolved( >>>+ target=self.info['dns_domain'], >>>+ conflict=another_domain.info['dns_domain']) >>>""" >>> >>>Patch 218: >>> >>>1.) >>>typo in the commit message: >>> >>>""" >>>... >>>suffixes are forest-wide, there *are could be* user accounts in the >>>... >>>""" >>> >>>2.) >>>A stupid question I know, but why do we need to replace empty string >>>with None here? >>> >>>""" >>> # with the forest, thus we have to use >>>netr_DsRGetForestTrustInformation >>>- domains = >>>netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], '', 0) >>>+ domains = >>>netr_pipe.netr_DsRGetForestTrustInformation(td.info['dc'], None, 0) >>>""" >>I'm answering this one while working on the other fixes. >> >>netr_DsRGetForestTrustInformation() uses NULL to say a parameter is >>missing, not empty string. It actually causes an issue if we don't do >>that when asking a domain controller from a domain that is not a root >>domain of the forest where we get currently undocumented error >>NERR_ACFNotLoaded (0x000008b3). If non-NULL name is specified, AD domain >>controller will perform proper operation only if it is a domain >>controller from the forest root domain and the domain specified is >>known. Obviously, a domain named '' cannot be known. This breaks >>external trust. >> >>Perhaps, this could be moved into a separate patch on its own. >> > >+1 for separate patch, thank you for your explanation. No need for separate patch -- see my explanation in the other email. -- / Alexander Bokovoy From slaznick at redhat.com Wed Aug 17 11:47:40 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 17 Aug 2016 13:47:40 +0200 Subject: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument In-Reply-To: References: <7a64f453-df5a-0691-746c-1b04c7171f8a@redhat.com> <47ac8912-1caf-bdd8-bb32-fdb29dffffb8@redhat.com> <3b23492e-17e7-13e1-1099-16cfb0963c98@redhat.com> Message-ID: <0a43fba5-a300-27e6-2ef3-c4f8d907cda4@redhat.com> On 08/11/2016 02:59 PM, Stanislav Laznicka wrote: > On 08/11/2016 07:49 AM, Jan Cholasta wrote: >> On 2.8.2016 13:47, Stanislav Laznicka wrote: >>> On 07/19/2016 09:20 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 14.7.2016 14:36, Stanislav Laznicka wrote: >>>>> Hello, >>>>> >>>>> This patch fixes https://fedorahosted.org/freeipa/ticket/5640. >>>>> >>>>> With not so much experience with the framework, it raises question >>>>> in my >>>>> head whether ipaldap.get_entries is used properly throughout the >>>>> system >>>>> - does it always assume that it gets ALL the requested entries or >>>>> just a >>>>> few of those as configured by the 'ipaSearchRecordsLimit' >>>>> attribute of >>>>> ipaConfig.etc which it actually gets? >>>> >>>> That depends. If you call get_entries() on the ldap2 plugin (which is >>>> usually the case in the framework), then ipaSearchRecordsLimit is >>>> used. If you call it on some arbitrary LDAPClient instance, the >>>> hardcoded default (= unlimited) is used. >>>> >>>>> >>>>> One spot that I know the get_entries method was definitely not used >>>>> properly before this patch is in the >>>>> baseldap.LDAPObject.get_memberindirect() method: >>>>> >>>>> 692 result = self.backend.get_entries( >>>>> 693 self.api.env.basedn, >>>>> 694 filter=filter, >>>>> 695 attrs_list=['member'], >>>>> 696 size_limit=-1, # paged search will get >>>>> everything >>>>> anyway >>>>> 697 paged_search=True) >>>>> >>>>> which to me seems kind of important if the environment size_limit >>>>> is not >>>>> set properly :) The patch does not fix the non-propagation of the >>>>> paged_search, though. >>>> >>>> Why do you think size_limit is not used properly here? >>> AFAIU it is desired that the search is unlimited. However, due to the >>> fact that neither size_limit nor paged_search are passed from >>> ldap2.get_entries() to ldap2.find_entries() (methods inherited from >>> LDAPClient), only the number of records specified by >>> ipaSearchRecordsLimit is returned. That could eventually cause problems >>> should ipaSearchRecordsLimit be set to a low value as in the ticket. >> >> I see. This is *not* intentional, the **kwargs of get_entries() >> should be passed to find_entries(). This definitely needs to be fixed. >> >>>> >>>> Anyway, this ticket is not really easily fixable without more profound >>>> changes. Often, multiple LDAP searches are done during command >>>> execution. What do you do with the size limit then? Do you pass the >>>> same size limit to all the searches? Do you subtract the result size >>>> from the size limit after each search? Do you do something else with >>>> it? ... The answer is that it depends on the purpose of each >>>> individual LDAP search (like in get_memberindirect() above, we have to >>>> do unlimited search, otherwise the resulting entry would be >>>> incomplete), and fixing this accross the whole framework is a >>>> non-trivial task. >>>> >>> I do realize that the proposed fix for the permission plugin is not >>> perfect, it would probably be better to subtract the number of >>> currently >>> loaded records from the sizelimit, although in the end the number of >>> returned values will not be higher than the given size_limit. However, >>> it seems reasonable that if get_entries is passed a size limit, it >>> should apply it over current ipaSearchRecordsLimit rather than ignoring >>> it. Then, any use of get_entries could be fixed accordingly if someone >>> sees fit. >>> >> >> Right. Anyway, this is a different issue than above, so please put >> this into a separate commit. >> > Please see the attached patches, then. > Self-NACK, with Honza's help I found there was a mistake in the code. I also found an off-by-one bug which I hope I could stick to the other two patches (attaching only the modified and new patches). -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0062-2-fix-permission_find-fail-on-low-search-size-limit.patch Type: text/x-patch Size: 1597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0064-permission-find-fix-a-sizelimit-off-by-one-bug.patch Type: text/x-patch Size: 2183 bytes Desc: not available URL: From mbasti at redhat.com Wed Aug 17 11:48:52 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 17 Aug 2016 13:48:52 +0200 Subject: [Freeipa-devel] [PATCHES 681-682] cert: speed up cert-find, do not crash on invalid data in cert-find In-Reply-To: <08643229-deae-44a8-cacc-555df5d8ab41@redhat.com> References: <5fdd4314-7c3f-242d-1648-0aae521f1743@redhat.com> <35ddad7d-664a-1231-c8ae-afd4d4b43443@redhat.com> <39d4c373-81b3-9379-d198-7bcb0bf42f0f@redhat.com> <08643229-deae-44a8-cacc-555df5d8ab41@redhat.com> Message-ID: <3d44699e-bc18-5746-1734-ff1cf3f5be61@redhat.com> On 17.08.2016 10:27, Jan Cholasta wrote: > On 16.8.2016 17:01, Martin Basti wrote: >> >> >> On 16.08.2016 17:00, Pavel Vomacka wrote: >>> >>> >>> On 08/12/2016 08:29 AM, Jan Cholasta wrote: >>>> On 11.8.2016 19:43, Martin Basti wrote: >>>>> >>>>> >>>>> On 11.08.2016 16:09, Jan Cholasta wrote: >>>>>> On 11.8.2016 14:27, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 01.08.2016 10:27, Jan Cholasta wrote: >>>>>>>> On 1.8.2016 10:19, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> the attached patches fix >>>>>>>>> >>>>>>>>> and . >>>>>>>> >>>>>>>> Self-NACK, proper patches attached. >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> IMHO this is caused by your patches, test_cert_plugin.py: >>>>>> >>>>>> Fixed. >>>>>> >>>>>> Updated and rebased patches attached. >>>>>> >>>>> Hello, >>>>> >>>>> It works for me, but: >>>>> >>>>> 1) >>>>> Is this py2/3 compatible? >>>>> ra_obj = ra.get_certificate(str(serial_number)) >>>> >>>> I don't see why not. Do you have any particular incompatibility in >>>> mind? >>>> >>>>> >>>>> 2) >>>>> Are you sure you need tuple() here? >>>>> + for key in tuple(six.iterkeys(result)): >>>> >>>> Yes, I'm modifying `result` inside the loop. >>>> >>>> I don't need the six.iterkeys() though. >>>> >>>>> >>>>> 3) >>>>> if cert is not None: >>>>> filter = ldap.make_filter_from_attr('usercertificate', >>>>> value) >>>>> filters.append(filter) >>>>> >>>>> Variable "value" may be referenced before assignment >>>> >>>> Right, it should be `cert`, not `value`. >>>> >>>>> >>>>> I haven't tested performace improvements yet, and it is quite big >>>>> change >>>>> so I will continue with testing tomorrow. >>> I tested performance improvements and cert-find in webui with 71 >>> certificates took about 10 seconds before these patches, now it is >>> about 400ms (even with more certs) . So works for me perfectly. From >>> CLI it took about 10 seconds now around 4 seconds. >> >> Please fix reported issues by me, and we can push it. > > Here you go. > ACK master: * c718ef058847bb39e78236e8af0ad69ac961bbcf cert: speed up cert-find * 8ad03259fe770b222e70286fd00c3416b4ed197d cert: do not crash on invalid data in cert-find From mbasti at redhat.com Wed Aug 17 11:59:27 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 17 Aug 2016 13:59:27 +0200 Subject: [Freeipa-devel] [PATCH] 0106, 0107: webui: add warning that only one CA server exists In-Reply-To: <505e8da3-9a44-eeea-d2c4-e72ba65b2290@redhat.com> References: <505e8da3-9a44-eeea-d2c4-e72ba65b2290@redhat.com> Message-ID: <8dc1adde-a86f-daac-c4d0-16976a428d07@redhat.com> On 17.08.2016 12:54, Tomas Krizek wrote: > > ACK, works for me. > > > On 08/16/2016 10:43 AM, Pavel Vomacka wrote: >> Hello, >> >> Please review attached patches which adds warning that only one CA >> server is installed. >> >> https://fedorahosted.org/freeipa/ticket/5828 >> >> >> > > -- > Tomas Krizek > > master: * d45b0efe5d5f718791d34a3e57ea723dcae8fd59 Add warning about only one existing CA server * ff51e43a3eb2431f253a25351b1b6378224c4b66 Set servers list as default facet in topology facet group -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Aug 17 12:17:03 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Aug 2016 14:17:03 +0200 Subject: [Freeipa-devel] [PATCH 0112-7] Speeding up cli help In-Reply-To: <1ff6376d-e47b-cceb-0661-c66f2e3e4133@redhat.com> References: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> <01ff40a4-b964-4f78-33dd-f1c92c490fdd@redhat.com> <29310e45-fc18-52fc-1686-651bb42480c9@redhat.com> <547fcaaa-c86c-f547-c049-2de82df78de8@redhat.com> <1ff6376d-e47b-cceb-0661-c66f2e3e4133@redhat.com> Message-ID: On 17.8.2016 13:21, David Kupka wrote: > On 08/08/16 13:26, Jan Cholasta wrote: >> On 4.8.2016 16:32, David Kupka wrote: >>> On 03/08/16 16:33, Jan Cholasta wrote: >>>> On 3.8.2016 16:23, David Kupka wrote: >>>>> On 21/07/16 10:12, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 20.7.2016 14:32, David Kupka wrote: >>>>>>> On 15/07/16 12:53, David Kupka wrote: >>>>>>>> Hello! >>>>>>>> >>>>>>>> After Honza introduced thin client that builds plugins and commands >>>>>>>> dynamically from schema client became much slower. This is only >>>>>>>> logical, >>>>>>>> instead of importing a module client now must fetch the schema from >>>>>>>> server, parse it and instantiate the commands using the data. >>>>>>>> >>>>>>>> First step to speed it up was addition of schema cache to client. >>>>>>>> That >>>>>>>> removed the RTT and download time of fetching schema every time. >>>>>>>> >>>>>>>> Now the most time consuming task became displaying help for >>>>>>>> lists of >>>>>>>> topics and command and displaying individual topics. This is simply >>>>>>>> because of the need to instantiate all the commands to find the >>>>>>>> relations between topics and commands. >>>>>>>> >>>>>>>> All the necessary bits for server commands and topics are >>>>>>>> already in >>>>>>>> the >>>>>>>> schema cache so we can skip this part and generate help from it, >>>>>>>> right? >>>>>>>> Not so fast! >>>>>>>> >>>>>>>> There are client plugins with commands and topics. So we can >>>>>>>> generate >>>>>>>> basic bits (list of all topics, list of all commands, list of >>>>>>>> commands >>>>>>>> for each topic) from schema and store it in cache. Then we need >>>>>>>> to go >>>>>>>> through all client plugins and get similar bits for client plugins. >>>>>>>> Then >>>>>>>> we can merge and print. >>>>>>>> >>>>>>>> Still the client response is not as fast as before and I this it >>>>>>>> even >>>>>>>> can't be. Also first time you display particular topic or list >>>>>>>> takes >>>>>>>> longer because it must be freshly generated and stored in cache for >>>>>>>> next >>>>>>>> use. And this is what the attached patches do. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/6048 >>>>>>> >>>>>>> Reimplemented so there is no need to distinguish client plugins and >>>>>>> remote plugins. >>>>>>> The main idea of this approach is to avoid creating instances of the >>>>>>> commands just to get the information about topic, name and summary >>>>>>> needed for displaying help. Instead class properties are used to >>>>>>> access >>>>>>> the information directly in schema. >>>>>> >>>>>> Patch 0112: >>>>>> >>>>>> I think this would better be done in Schema.read_namespace_member, >>>>>> because Schema is where all the state is. >>>>>> >>>>>> (BTW does _SchemaNameSpace.__getitem__ raise KeyError for >>>>>> non-existent >>>>>> keys? It looks like it doesn't.) >>>>>> >>>>>> >>>>>> Patch 0113: >>>>>> >>>>>> How about setting _schema_cached to False in Schema.__init__() rather >>>>>> that getattr()-ing it in _ensure_cached()? >>>>>> >>>>>> >>>>>> Patch 0116: >>>>>> >>>>>> ClientCommand.doc should be a class property as well, otherwise >>>>>> .summary >>>>>> won't work on it correctly. >>>>>> >>>>>> _SchemaCommand.doc should not be a property, as it's not needed for >>>>>> .summary to work on it correctly. >>>>>> >>>>>> >>>>>> Otherwise works fine for me. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> Updated patches attached. >>>> >>>> Thanks, ACK. >>>> >>>> Pushed to master: 229e2a1ed9ea9877cb5e879fadd99f9040f77c96 >>>> >>> >>> I've made and reviewer overlooked some errors. Attached patches fix >>> them. >> >> Shame on me. >> >> Anyway, >> >> 1) When schema() raises SchemaUpToDate, the current code explodes: >> >> ipa: ERROR: KeyError: 'fingerprint' >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1348, in >> run >> api.finalize() >> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 707, >> in finalize >> self.__do_if_not_done('load_plugins') >> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 422, >> in __do_if_not_done >> getattr(self, name)() >> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 585, >> in load_plugins >> for package in self.packages: >> File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 919, >> in packages >> ipaclient.remote_plugins.get_package(self), >> File >> "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", >> line 92, in get_package >> plugins = schema.get_package(api, server_info, client) >> File >> "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", >> line 558, in get_package >> fingerprint = str(schema['fingerprint']) >> File >> "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", >> line 483, in __getitem__ >> return self._dict[key] >> KeyError: 'fingerprint' >> >> >> 2) We read server info every time get_package() is called. It should be >> cache similarly to how the schema is cached in the api object. >> >> >> 3) Some of the commands are still fully initialized during "ipa help >> commands". >> >> >> Honza >> > Updated patches attached. Thanks, ACK. Pushed to master: 6e6cbda036559e741ead0ab5ba18b0be0b41621e -- Jan Cholasta From pspacek at redhat.com Wed Aug 17 12:17:22 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 17 Aug 2016 14:17:22 +0200 Subject: [Freeipa-devel] Announcing bind-dyndb-ldap version 10.1 Message-ID: The FreeIPA team is proud to announce bind-dyndb-ldap version 10.1. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 24+: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ea30aafae1 Latest news: 10.1 ==== [1] Prevent crash while reloading previously invalid but now valid DNS zone. https://fedorahosted.org/bind-dyndb-ldap/ticket/166 [2] Fix zone removal to respect forward configuration inheritance. https://fedorahosted.org/bind-dyndb-ldap/ticket/167 10.0 ==== [1] Default TTL can be configured at zone level in dNSdefaultTTL attribute. Please note that changes may not be applied until server reload. https://fedorahosted.org/bind-dyndb-ldap/ticket/70 [2] Certain subset of configuration options can be specified in idnsServerConfigObject in LDAP. Each bind-dyndb-ldap instance will only use values from object with idnsServerId attribute matching server_id configured in named.conf. This can be used for per-server configuration in shared LDAP tree. https://fedorahosted.org/bind-dyndb-ldap/ticket/162 [2] fake_mname option can be specified in idnsServerConfigObject in LDAP. Please note that changes may not be applied until server reload. https://fedorahosted.org/bind-dyndb-ldap/ticket/162 [3] Per-server global forwarders can be configured in idnsServerConfigObject. https://fedorahosted.org/bind-dyndb-ldap/ticket/162 [4] Dynamic record generation using idnsTemplateObject and idnsSubstitutionVariable;ipalocation attribute from idnsServerConfigObject is supported. Please see README. Please note that changes may not be applied until server reload. https://fedorahosted.org/bind-dyndb-ldap/ticket/126 [5] Forwarding configuration is properly ignored for disabled master zones. [6] Interaction between DNS root zone and global forwarding is now deterministic and root zone has higher priority over global forwarding. [7] Various problems in internal event processing were fixed. [8] Potential crash in early start-up phase was fixed. [9] Compatibility with BIND >= 9.10.4b1 was improved == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. Downgrading back to any 9.x version is supported as long as new features are not used. FreeIPA users have to upgrade to version 10.0 or newer before enabling 'DNS locations' feature in FreeIPA. == Advance notification: Limited compatibility with BIND 9 == Please note that bind-dyndb-ldap 10.x is the last branch compatible with BIND 9.10 or older. bind-dyndb-ldap version 11.0 will be compatible only with BIND 9.11 and newer. At the same time, version 11.0 will introduce incompatible changes to configuration format. == Feedback == Please provide comments, report bugs, and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr^2 Spacek From mbabinsk at redhat.com Wed Aug 17 12:17:54 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 17 Aug 2016 14:17:54 +0200 Subject: [Freeipa-devel] [PATCH 0063] Raise error on topology disconnect/last-role-host removal during server uninstall In-Reply-To: <647de12f-7f08-54c3-87c6-e56d34f236a3@redhat.com> References: <4b103ebb-cd29-1705-456f-fd7965abc2a6@redhat.com> <448657e9-d35d-ffa9-8582-761c3d733aa9@redhat.com> <647de12f-7f08-54c3-87c6-e56d34f236a3@redhat.com> Message-ID: On 08/16/2016 03:47 PM, Stanislav Laznicka wrote: > On 08/15/2016 02:20 PM, Martin Babinsky wrote: >> On 08/15/2016 02:13 PM, Martin Babinsky wrote: >>> On 08/12/2016 12:08 PM, Stanislav Laznicka wrote: >>>> Hello, >>>> >>>> topology disconnect/last-role-host removal errors would just be logged >>>> during server uninstall even if ignore options are not present. The >>>> host >>>> would still appear in the topology even after "successful" uninstall. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6168 >>>> >>>> >>>> >>> >>> The patch seems to be ok, however shouldn't we use sys.exit() when >>> handling ServerRemovalError? Yes raising SystemExit from within a >>> function is a horrible practice, but it is already done on several other >>> places instead of letting the exception bubble up to the main handler. >>> >>> CC'ing Jan for his thoughts on this since I may be wrong. >>> >> Hmm, you will definitely need sys.exit() here since otherwise >> ipa-server-install reports 0 exit code even if there was an exception >> thrown: >> >> """ >> [root at master1 ~]# ipa-server-install --uninstall -U >> ipa : ERROR Server removal aborted: Deleting this server >> will leave your installation without a DNS.. >> [root at master1 ~]# echo $? >> 0 >> """ >> > Because of #5750 (remove sys.exit() calls from installer modules) I > rather raise ScriptError in this case. See the modified patch. It > depends on either of my 48-4 or 48-5 patches (pick one). > Make sure you raise it using str(e) because ScriptError does not coerce the argument to string/unicode: @@ -303,7 +303,7 @@ def remove_master_from_managed_topology(api_instance, options): replication.run_server_del_as_cli( api_instance, api_instance.env.host, **server_del_options) except errors.ServerRemovalError as e: - raise ScriptError(e) + raise ScriptError(str(e)) except Exception as e: # if the master was already deleted we will just get a warning root_logger.warning("Failed to delete master: {}".format(e)) Regardless of this fix, I still get exit code 0 after exception is raised: """ [root at client1 ~]# ipa-server-install --uninstall -U This server is active DNSSEC key master. Uninstall could break your DNS system. ipa : ERROR Server removal aborted: Replica is active DNSSEC key master. Uninstall could break your DNS system. Please disable or replace DNSSEC key master first.. [root at client1 ~]# echo $? 0 """ I guess there is nothing we can do about this now as the fix for this seems to be beyond the scope of this patch ( or am I mistaken?). -- Martin^3 Babinsky From slaznick at redhat.com Wed Aug 17 12:38:34 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 17 Aug 2016 14:38:34 +0200 Subject: [Freeipa-devel] [PATCH 0063] Raise error on topology disconnect/last-role-host removal during server uninstall In-Reply-To: References: <4b103ebb-cd29-1705-456f-fd7965abc2a6@redhat.com> <448657e9-d35d-ffa9-8582-761c3d733aa9@redhat.com> <647de12f-7f08-54c3-87c6-e56d34f236a3@redhat.com> Message-ID: <6995699e-3ec8-aec3-f7b3-a2f2fac173f0@redhat.com> On 08/17/2016 02:17 PM, Martin Babinsky wrote: > On 08/16/2016 03:47 PM, Stanislav Laznicka wrote: >> On 08/15/2016 02:20 PM, Martin Babinsky wrote: >>> On 08/15/2016 02:13 PM, Martin Babinsky wrote: >>>> On 08/12/2016 12:08 PM, Stanislav Laznicka wrote: >>>>> Hello, >>>>> >>>>> topology disconnect/last-role-host removal errors would just be >>>>> logged >>>>> during server uninstall even if ignore options are not present. The >>>>> host >>>>> would still appear in the topology even after "successful" uninstall. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6168 >>>>> >>>>> >>>>> >>>> >>>> The patch seems to be ok, however shouldn't we use sys.exit() when >>>> handling ServerRemovalError? Yes raising SystemExit from within a >>>> function is a horrible practice, but it is already done on several >>>> other >>>> places instead of letting the exception bubble up to the main handler. >>>> >>>> CC'ing Jan for his thoughts on this since I may be wrong. >>>> >>> Hmm, you will definitely need sys.exit() here since otherwise >>> ipa-server-install reports 0 exit code even if there was an exception >>> thrown: >>> >>> """ >>> [root at master1 ~]# ipa-server-install --uninstall -U >>> ipa : ERROR Server removal aborted: Deleting this server >>> will leave your installation without a DNS.. >>> [root at master1 ~]# echo $? >>> 0 >>> """ >>> >> Because of #5750 (remove sys.exit() calls from installer modules) I >> rather raise ScriptError in this case. See the modified patch. It >> depends on either of my 48-4 or 48-5 patches (pick one). >> > > Make sure you raise it using str(e) because ScriptError does not > coerce the argument to string/unicode: > > @@ -303,7 +303,7 @@ def > remove_master_from_managed_topology(api_instance, options): > replication.run_server_del_as_cli( > api_instance, api_instance.env.host, **server_del_options) > except errors.ServerRemovalError as e: > - raise ScriptError(e) > + raise ScriptError(str(e)) > except Exception as e: > # if the master was already deleted we will just get a warning > root_logger.warning("Failed to delete master: {}".format(e)) > Oops, sorry, attached is the fixed patch. > Regardless of this fix, I still get exit code 0 after exception is > raised: > > """ > [root at client1 ~]# ipa-server-install --uninstall -U > This server is active DNSSEC key master. Uninstall could break your > DNS system. > ipa : ERROR Server removal aborted: Replica is active > DNSSEC key master. Uninstall could break your DNS system. Please > disable or replace DNSSEC key master first.. > [root at client1 ~]# echo $? > 0 > """ > > I guess there is nothing we can do about this now as the fix for this > seems to be beyond the scope of this patch ( or am I mistaken?). > Dandy. The actual relevant ticket to zero return value no matter what is already there - https://fedorahosted.org/freeipa/ticket/5725. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0063-3-Fail-on-topology-disconnect-last-role-removal.patch Type: text/x-patch Size: 1646 bytes Desc: not available URL: From pvomacka at redhat.com Wed Aug 17 12:42:53 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 17 Aug 2016 14:42:53 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> Message-ID: <7352976a-17aa-7144-9952-dc9a3497801c@redhat.com> On 08/11/2016 07:49 PM, Petr Vobornik wrote: > On 08/11/2016 07:21 PM, Martin Basti wrote: >> >> On 11.08.2016 18:57, Pavel Vomacka wrote: >>> >>> On 08/11/2016 02:00 PM, Petr Vobornik wrote: >>>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >>>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >>>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >>>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >>>>>>>> Got it. One thing I would correct, though, -- don't use >>>>>>>> kadmin.local, we >>>>>>>> do support setting ok_as_delegate on the service principals via IPA >>>>>>>> CLI: >>>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>>>>>>> --ok-as-delegate=BOOL >>>>>>>> Client credentials may be delegated to the >>>>>>>> service >>>>>>> I've tried >>>>>>> >>>>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >>>>>>> >>>>>>> but that does not seem to have the same effect as >>>>>>> >>>>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >>>>>>> >>>>>>> -- obtaining the delegated certificated fails. >>>>>> That's because ok_as_delegate and ok_to_auth_as_delegate are different >>>>>> flags. >>>>> Right. The following patch adds ok_to_auth_as_delegate to the service >>>>> principal. >>>>> >>>>> I haven't added any tickets to it yet. >>>>> >>>>> >>>> This might deserve also nice Web UI checkbox similar to "Trusted for >>>> delegation". CCing Pavel. >>>> >>> Here is patch with new checkbox. It is without ticket in commit message so >>> once we will have the ticket I will send another patch witch updated commit >>> message. >> https://fedorahosted.org/freeipa/newticket >> >> ;-) > It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 so we > might use that. Thank you, patch with updated commit message attached. -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0105-2-Add-trusted-to-auth-as-user-checkbox.patch Type: text/x-patch Size: 1154 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Aug 17 12:58:47 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 17 Aug 2016 14:58:47 +0200 Subject: [Freeipa-devel] [PATCH 0063] Raise error on topology disconnect/last-role-host removal during server uninstall In-Reply-To: <6995699e-3ec8-aec3-f7b3-a2f2fac173f0@redhat.com> References: <4b103ebb-cd29-1705-456f-fd7965abc2a6@redhat.com> <448657e9-d35d-ffa9-8582-761c3d733aa9@redhat.com> <647de12f-7f08-54c3-87c6-e56d34f236a3@redhat.com> <6995699e-3ec8-aec3-f7b3-a2f2fac173f0@redhat.com> Message-ID: On 08/17/2016 02:38 PM, Stanislav Laznicka wrote: > On 08/17/2016 02:17 PM, Martin Babinsky wrote: >> On 08/16/2016 03:47 PM, Stanislav Laznicka wrote: >>> On 08/15/2016 02:20 PM, Martin Babinsky wrote: >>>> On 08/15/2016 02:13 PM, Martin Babinsky wrote: >>>>> On 08/12/2016 12:08 PM, Stanislav Laznicka wrote: >>>>>> Hello, >>>>>> >>>>>> topology disconnect/last-role-host removal errors would just be >>>>>> logged >>>>>> during server uninstall even if ignore options are not present. The >>>>>> host >>>>>> would still appear in the topology even after "successful" uninstall. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6168 >>>>>> >>>>>> >>>>>> >>>>> >>>>> The patch seems to be ok, however shouldn't we use sys.exit() when >>>>> handling ServerRemovalError? Yes raising SystemExit from within a >>>>> function is a horrible practice, but it is already done on several >>>>> other >>>>> places instead of letting the exception bubble up to the main handler. >>>>> >>>>> CC'ing Jan for his thoughts on this since I may be wrong. >>>>> >>>> Hmm, you will definitely need sys.exit() here since otherwise >>>> ipa-server-install reports 0 exit code even if there was an exception >>>> thrown: >>>> >>>> """ >>>> [root at master1 ~]# ipa-server-install --uninstall -U >>>> ipa : ERROR Server removal aborted: Deleting this server >>>> will leave your installation without a DNS.. >>>> [root at master1 ~]# echo $? >>>> 0 >>>> """ >>>> >>> Because of #5750 (remove sys.exit() calls from installer modules) I >>> rather raise ScriptError in this case. See the modified patch. It >>> depends on either of my 48-4 or 48-5 patches (pick one). >>> >> >> Make sure you raise it using str(e) because ScriptError does not >> coerce the argument to string/unicode: >> >> @@ -303,7 +303,7 @@ def >> remove_master_from_managed_topology(api_instance, options): >> replication.run_server_del_as_cli( >> api_instance, api_instance.env.host, **server_del_options) >> except errors.ServerRemovalError as e: >> - raise ScriptError(e) >> + raise ScriptError(str(e)) >> except Exception as e: >> # if the master was already deleted we will just get a warning >> root_logger.warning("Failed to delete master: {}".format(e)) >> > Oops, sorry, attached is the fixed patch. >> Regardless of this fix, I still get exit code 0 after exception is >> raised: >> >> """ >> [root at client1 ~]# ipa-server-install --uninstall -U >> This server is active DNSSEC key master. Uninstall could break your >> DNS system. >> ipa : ERROR Server removal aborted: Replica is active >> DNSSEC key master. Uninstall could break your DNS system. Please >> disable or replace DNSSEC key master first.. >> [root at client1 ~]# echo $? >> 0 >> """ >> >> I guess there is nothing we can do about this now as the fix for this >> seems to be beyond the scope of this patch ( or am I mistaken?). >> > Dandy. The actual relevant ticket to zero return value no matter what is > already there - https://fedorahosted.org/freeipa/ticket/5725. > Ok then. ACK. Pushed to master: fea56fefff48b0d8eb147c2c2c511c869a1eadf0 -- Martin^3 Babinsky From pvomacka at redhat.com Wed Aug 17 13:07:20 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 17 Aug 2016 15:07:20 +0200 Subject: [Freeipa-devel] [PATCH 688] server install: do not prompt for cert file PIN repeatedly In-Reply-To: <79609ecc-aaf3-2388-a64d-379fcb0605a2@redhat.com> References: <79609ecc-aaf3-2388-a64d-379fcb0605a2@redhat.com> Message-ID: <84b91763-d6a1-0912-6d9d-0e464cea3f77@redhat.com> On 08/17/2016 10:24 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > ACK. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Aug 17 13:12:25 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Aug 2016 15:12:25 +0200 Subject: [Freeipa-devel] [PATCH 688] server install: do not prompt for cert file PIN repeatedly In-Reply-To: <84b91763-d6a1-0912-6d9d-0e464cea3f77@redhat.com> References: <79609ecc-aaf3-2388-a64d-379fcb0605a2@redhat.com> <84b91763-d6a1-0912-6d9d-0e464cea3f77@redhat.com> Message-ID: <1a55cf20-decb-9ea4-c9ba-f3cf43748e91@redhat.com> On 17.8.2016 15:07, Pavel Vomacka wrote: > > > On 08/17/2016 10:24 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > ACK. Thanks. Pushed to master: 4ee426a68ec60370eee6f5aec917ecce444840c7 -- Jan Cholasta From slaznick at redhat.com Wed Aug 17 13:36:36 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 17 Aug 2016 15:36:36 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> Message-ID: <6d157c60-8658-70e4-2213-e3573fc19eac@redhat.com> On 08/16/2016 03:16 PM, Tibor Dudlak wrote: > Hi, > > I have edited this patch after review. It should be okay now. > > Thank you. > > On Thu, Aug 11, 2016 at 7:49 PM, Petr Vobornik > wrote: > > On 08/11/2016 07:21 PM, Martin Basti wrote: > > > > > > On 11.08.2016 18:57, Pavel Vomacka wrote: > >> > >> > >> On 08/11/2016 02:00 PM, Petr Vobornik wrote: > >>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: > >>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: > >>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: > >>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy > wrote: > >>>>>>> Got it. One thing I would correct, though, -- don't use > >>>>>>> kadmin.local, we > >>>>>>> do support setting ok_as_delegate on the service > principals via IPA > >>>>>>> CLI: > >>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate > >>>>>>> --ok-as-delegate=BOOL > >>>>>>> Client credentials may be delegated to the > >>>>>>> service > >>>>>> I've tried > >>>>>> > >>>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) > >>>>>> > >>>>>> but that does not seem to have the same effect as > >>>>>> > >>>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test > >>>>>> > >>>>>> -- obtaining the delegated certificated fails. > >>>>> That's because ok_as_delegate and ok_to_auth_as_delegate are > different > >>>>> flags. > >>>> Right. The following patch adds ok_to_auth_as_delegate to the > service > >>>> principal. > >>>> > >>>> I haven't added any tickets to it yet. > >>>> > >>>> > >>> This might deserve also nice Web UI checkbox similar to > "Trusted for > >>> delegation". CCing Pavel. > >>> > >> Here is patch with new checkbox. It is without ticket in commit > message so > >> once we will have the ticket I will send another patch witch > updated commit > >> message. > > > > https://fedorahosted.org/freeipa/newticket > > > > > ;-) > > It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 > so we > might use that. > > Please, add your answers at the end of the previous mail in the future. Also, your patch raises pep8 errors: ./ipaserver/plugins/xmlserver.py:31:80: E501 line too long (189 > 79 characters) ./ipaserver/rpcserver.py:885:5: E113 unexpected indentation Could you please fix them? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvomacka at redhat.com Wed Aug 17 13:50:30 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 17 Aug 2016 15:50:30 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <7352976a-17aa-7144-9952-dc9a3497801c@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> <7352976a-17aa-7144-9952-dc9a3497801c@redhat.com> Message-ID: <393a23e7-a4a5-63ac-2fe7-a81fa179f824@redhat.com> On 08/17/2016 02:42 PM, Pavel Vomacka wrote: > > > On 08/11/2016 07:49 PM, Petr Vobornik wrote: >> On 08/11/2016 07:21 PM, Martin Basti wrote: >>> >>> On 11.08.2016 18:57, Pavel Vomacka wrote: >>>> >>>> On 08/11/2016 02:00 PM, Petr Vobornik wrote: >>>>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >>>>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >>>>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >>>>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >>>>>>>>> Got it. One thing I would correct, though, -- don't use >>>>>>>>> kadmin.local, we >>>>>>>>> do support setting ok_as_delegate on the service principals >>>>>>>>> via IPA >>>>>>>>> CLI: >>>>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>>>>>>>> --ok-as-delegate=BOOL >>>>>>>>> Client credentials may be delegated to >>>>>>>>> the >>>>>>>>> service >>>>>>>> I've tried >>>>>>>> >>>>>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >>>>>>>> >>>>>>>> but that does not seem to have the same effect as >>>>>>>> >>>>>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >>>>>>>> >>>>>>>> -- obtaining the delegated certificated fails. >>>>>>> That's because ok_as_delegate and ok_to_auth_as_delegate are >>>>>>> different >>>>>>> flags. >>>>>> Right. The following patch adds ok_to_auth_as_delegate to the >>>>>> service >>>>>> principal. >>>>>> >>>>>> I haven't added any tickets to it yet. >>>>>> >>>>>> >>>>> This might deserve also nice Web UI checkbox similar to "Trusted for >>>>> delegation". CCing Pavel. >>>>> >>>> Here is patch with new checkbox. It is without ticket in commit >>>> message so >>>> once we will have the ticket I will send another patch witch >>>> updated commit >>>> message. >>> https://fedorahosted.org/freeipa/newticket >>> >>> ;-) >> It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 so we >> might use that. > Thank you, patch with updated commit message attached. > > > Attached patch adds checkbox also to host page. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0105-3-Add-trusted-to-auth-as-user-checkbox.patch Type: text/x-patch Size: 2037 bytes Desc: not available URL: From abokovoy at redhat.com Wed Aug 17 13:58:54 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Aug 2016 16:58:54 +0300 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> References: <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> Message-ID: <20160817135854.e7wxvwfpfnoww26m@redhat.com> On Thu, 11 Aug 2016, Petr Vobornik wrote: >On 08/11/2016 07:21 PM, Martin Basti wrote: >> >> >> On 11.08.2016 18:57, Pavel Vomacka wrote: >>> >>> >>> On 08/11/2016 02:00 PM, Petr Vobornik wrote: >>>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >>>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >>>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >>>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >>>>>>>> Got it. One thing I would correct, though, -- don't use >>>>>>>> kadmin.local, we >>>>>>>> do support setting ok_as_delegate on the service principals via IPA >>>>>>>> CLI: >>>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>>>>>>> --ok-as-delegate=BOOL >>>>>>>> Client credentials may be delegated to the >>>>>>>> service >>>>>>> I've tried >>>>>>> >>>>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >>>>>>> >>>>>>> but that does not seem to have the same effect as >>>>>>> >>>>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >>>>>>> >>>>>>> -- obtaining the delegated certificated fails. >>>>>> That's because ok_as_delegate and ok_to_auth_as_delegate are different >>>>>> flags. >>>>> Right. The following patch adds ok_to_auth_as_delegate to the service >>>>> principal. >>>>> >>>>> I haven't added any tickets to it yet. >>>>> >>>>> >>>> This might deserve also nice Web UI checkbox similar to "Trusted for >>>> delegation". CCing Pavel. >>>> >>> Here is patch with new checkbox. It is without ticket in commit message so >>> once we will have the ticket I will send another patch witch updated commit >>> message. >> >> https://fedorahosted.org/freeipa/newticket >> >> ;-) > >It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 so we >might use that. Sounds good. Patch with updated commit message is attached. -- / Alexander Bokovoy -------------- next part -------------- From e2cebaa4e4b30b588d484e111cb11779cb863c0f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 11 Aug 2016 11:52:05 +0300 Subject: [PATCH 06/10] service: add flag to allow S4U2Self Prerequisite for: https://fedorahosted.org/freeipa/ticket/5764 --- API.txt | 12 ++++++++---- VERSION | 4 ++-- ipaserver/plugins/service.py | 7 +++++++ 3 files changed, 17 insertions(+), 6 deletions(-) diff --git a/API.txt b/API.txt index 535d8ec..5b83bfb 100644 --- a/API.txt +++ b/API.txt @@ -2260,7 +2260,7 @@ output: Output('summary', type=[, ]) output: Output('value', type=[]) output: Output('warning', type=[, , ]) command: host_add/1 -args: 1,24,3 +args: 1,25,3 arg: Str('fqdn', cli_name='hostname') option: Str('addattr*', cli_name='addattr') option: Flag('all', autofill=True, cli_name='all', default=False) @@ -2269,6 +2269,7 @@ option: Flag('force', autofill=True, default=False) option: Str('ip_address?') option: Str('ipaassignedidview?') option: Bool('ipakrbokasdelegate?', cli_name='ok_as_delegate') +option: Bool('ipakrboktoauthasdelegate?', cli_name='ok_to_auth_as_delegate') option: Bool('ipakrbrequirespreauth?', cli_name='requires_pre_auth') option: Str('ipasshpubkey*', cli_name='sshpubkey') option: Str('krbprincipalauthind*', cli_name='auth_ind') @@ -2437,7 +2438,7 @@ output: ListOfEntries('result') output: Output('summary', type=[, ]) output: Output('truncated', type=[]) command: host_mod/1 -args: 1,25,3 +args: 1,26,3 arg: Str('fqdn', cli_name='hostname') option: Str('addattr*', cli_name='addattr') option: Flag('all', autofill=True, cli_name='all', default=False) @@ -2445,6 +2446,7 @@ option: Str('delattr*', cli_name='delattr') option: Str('description?', autofill=False, cli_name='desc') option: Str('ipaassignedidview?', autofill=False) option: Bool('ipakrbokasdelegate?', autofill=False, cli_name='ok_as_delegate') +option: Bool('ipakrboktoauthasdelegate?', autofill=False, cli_name='ok_to_auth_as_delegate') option: Bool('ipakrbrequirespreauth?', autofill=False, cli_name='requires_pre_auth') option: Str('ipasshpubkey*', autofill=False, cli_name='sshpubkey') option: Str('krbprincipalauthind*', autofill=False, cli_name='auth_ind') @@ -4293,13 +4295,14 @@ output: Entry('result') output: Output('summary', type=[, ]) output: PrimaryKey('value') command: service_add/1 -args: 1,12,3 +args: 1,13,3 arg: Principal('krbcanonicalname', cli_name='canonical_principal') option: Str('addattr*', cli_name='addattr') option: Flag('all', autofill=True, cli_name='all', default=False) option: Flag('force', autofill=True, default=False) option: StrEnum('ipakrbauthzdata*', cli_name='pac_type', values=[u'MS-PAC', u'PAD', u'NONE']) option: Bool('ipakrbokasdelegate?', cli_name='ok_as_delegate') +option: Bool('ipakrboktoauthasdelegate?', cli_name='ok_to_auth_as_delegate') option: Bool('ipakrbrequirespreauth?', cli_name='requires_pre_auth') option: Str('krbprincipalauthind*', cli_name='auth_ind') option: Flag('no_members', autofill=True, default=False) @@ -4435,13 +4438,14 @@ output: ListOfEntries('result') output: Output('summary', type=[, ]) output: Output('truncated', type=[]) command: service_mod/1 -args: 1,14,3 +args: 1,15,3 arg: Principal('krbcanonicalname', cli_name='canonical_principal') option: Str('addattr*', cli_name='addattr') option: Flag('all', autofill=True, cli_name='all', default=False) option: Str('delattr*', cli_name='delattr') option: StrEnum('ipakrbauthzdata*', autofill=False, cli_name='pac_type', values=[u'MS-PAC', u'PAD', u'NONE']) option: Bool('ipakrbokasdelegate?', autofill=False, cli_name='ok_as_delegate') +option: Bool('ipakrboktoauthasdelegate?', autofill=False, cli_name='ok_to_auth_as_delegate') option: Bool('ipakrbrequirespreauth?', autofill=False, cli_name='requires_pre_auth') option: Str('krbprincipalauthind*', autofill=False, cli_name='auth_ind') option: Principal('krbprincipalname*', autofill=False, cli_name='principal') diff --git a/VERSION b/VERSION index ca48996..a8b89ed 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=211 -# Last change: mbabinsk: allow 'value' output param in commands without primary key +IPA_API_VERSION_MINOR=212 +# Last change: ab: service: add flag to allow S4U2Self diff --git a/ipaserver/plugins/service.py b/ipaserver/plugins/service.py index a44dcaa..04d1916 100644 --- a/ipaserver/plugins/service.py +++ b/ipaserver/plugins/service.py @@ -171,11 +171,18 @@ ticket_flags_params = ( doc=_('Client credentials may be delegated to the service'), flags=['virtual_attribute', 'no_search'], ), + Bool('ipakrboktoauthasdelegate?', + cli_name='ok_to_auth_as_delegate', + label=_('Trusted to authenticate as user'), + doc=_('The service is allowed to authenticate on behalf of a client'), + flags=['virtual_attribute', 'no_search'], + ), ) _ticket_flags_map = { 'ipakrbrequirespreauth': 0x00000080, 'ipakrbokasdelegate': 0x00100000, + 'ipakrboktoauthasdelegate': 0x00200000, } _ticket_flags_default = _ticket_flags_map['ipakrbrequirespreauth'] -- 2.7.4 From tdudlak at redhat.com Wed Aug 17 14:11:58 2016 From: tdudlak at redhat.com (Tibor Dudlak) Date: Wed, 17 Aug 2016 16:11:58 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <6d157c60-8658-70e4-2213-e3573fc19eac@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> <6d157c60-8658-70e4-2213-e3573fc19eac@redhat.com> Message-ID: On Wed, Aug 17, 2016 at 3:36 PM, Stanislav Laznicka wrote: > On 08/16/2016 03:16 PM, Tibor Dudlak wrote: > > Hi, > > I have edited this patch after review. It should be okay now. > > Thank you. > > On Thu, Aug 11, 2016 at 7:49 PM, Petr Vobornik > wrote: > >> On 08/11/2016 07:21 PM, Martin Basti wrote: >> > >> > >> > On 11.08.2016 18:57, Pavel Vomacka wrote: >> >> >> >> >> >> On 08/11/2016 02:00 PM, Petr Vobornik wrote: >> >>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >> >>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >> >>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >> >>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >> >>>>>>> Got it. One thing I would correct, though, -- don't use >> >>>>>>> kadmin.local, we >> >>>>>>> do support setting ok_as_delegate on the service principals via >> IPA >> >>>>>>> CLI: >> >>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >> >>>>>>> --ok-as-delegate=BOOL >> >>>>>>> Client credentials may be delegated to the >> >>>>>>> service >> >>>>>> I've tried >> >>>>>> >> >>>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >> >>>>>> >> >>>>>> but that does not seem to have the same effect as >> >>>>>> >> >>>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >> >>>>>> >> >>>>>> -- obtaining the delegated certificated fails. >> >>>>> That's because ok_as_delegate and ok_to_auth_as_delegate are >> different >> >>>>> flags. >> >>>> Right. The following patch adds ok_to_auth_as_delegate to the service >> >>>> principal. >> >>>> >> >>>> I haven't added any tickets to it yet. >> >>>> >> >>>> >> >>> This might deserve also nice Web UI checkbox similar to "Trusted for >> >>> delegation". CCing Pavel. >> >>> >> >> Here is patch with new checkbox. It is without ticket in commit >> message so >> >> once we will have the ticket I will send another patch witch updated >> commit >> >> message. >> > >> > https://fedorahosted.org/freeipa/newticket >> > >> > ;-) >> >> It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 so we >> might use that. >> >> > Please, add your answers at the end of the previous mail in the future. > > Also, your patch raises pep8 errors: > ./ipaserver/plugins/xmlserver.py:31:80: E501 line too long (189 > 79 > characters) > ./ipaserver/rpcserver.py:885:5: E113 unexpected indentation > > Could you please fix them? > Hi, thanks for review Stanislav. I understand ./ipaserver/rpcserver.py:885:5: E113 unexpected indentation, that is my fault but really do not understand first one. Is there policy that you decided not to patch existing files, even if there was obviously longer line before patch until it is not necessary? Anyway I hope it should be ok now. Thank you. -- Tibor Dudl?k Intern - Identity management Special Projects Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tdudlak-0001-3-Added-new-authentication-method.patch Type: text/x-patch Size: 2868 bytes Desc: not available URL: From ldoudova at redhat.com Wed Aug 17 14:31:13 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 17 Aug 2016 16:31:13 +0200 Subject: [Freeipa-devel] [PATCH 0034][Tests] Fix failing tests in test_ipalib/test_parameters Message-ID: <9cfbb09c-46fd-7178-c136-cf8d86c4da92@redhat.com> Hi, attached patch fixes part of failing tests in ipatests/test_ipalib/test_parameters.py. Failures were caused mainly by thin client feature, sometimes by usage of unicode, which tests did not reflect. Issues were discussed with Honza. Remaining failing tests should be fixed in scope of one of Martin3's future patches (namely failures described in https://fedorahosted.org/freeipa/ticket/6190) Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0034-Tests-Fix-failing-tests-in-test_ipalib-test_paramete.patch Type: text/x-patch Size: 6629 bytes Desc: not available URL: From slaznick at redhat.com Wed Aug 17 14:33:35 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 17 Aug 2016 16:33:35 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> <6d157c60-8658-70e4-2213-e3573fc19eac@redhat.com> Message-ID: On 08/17/2016 04:11 PM, Tibor Dudlak wrote: > > On Wed, Aug 17, 2016 at 3:36 PM, Stanislav Laznicka > > wrote: > > On 08/16/2016 03:16 PM, Tibor Dudlak wrote: >> Hi, >> >> I have edited this patch after review. It should be okay now. >> >> Thank you. >> >> On Thu, Aug 11, 2016 at 7:49 PM, Petr Vobornik >> > wrote: >> >> On 08/11/2016 07:21 PM, Martin Basti wrote: >> > >> > >> > On 11.08.2016 18:57, Pavel Vomacka wrote: >> >> >> >> >> >> On 08/11/2016 02:00 PM, Petr Vobornik wrote: >> >>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >> >>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >> >>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >> >>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander >> Bokovoy wrote: >> >>>>>>> Got it. One thing I would correct, though, -- don't use >> >>>>>>> kadmin.local, we >> >>>>>>> do support setting ok_as_delegate on the service >> principals via IPA >> >>>>>>> CLI: >> >>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >> >>>>>>> --ok-as-delegate=BOOL >> >>>>>>> Client credentials may be delegated to the >> >>>>>>> service >> >>>>>> I've tried >> >>>>>> >> >>>>>> ipa service-mod --ok-as-delegate=True >> HTTP/$(hostname) >> >>>>>> >> >>>>>> but that does not seem to have the same effect as >> >>>>>> >> >>>>>> modprinc +ok_to_auth_as_delegate >> HTTP/ipa.example.test >> >>>>>> >> >>>>>> -- obtaining the delegated certificated fails. >> >>>>> That's because ok_as_delegate and >> ok_to_auth_as_delegate are different >> >>>>> flags. >> >>>> Right. The following patch adds ok_to_auth_as_delegate >> to the service >> >>>> principal. >> >>>> >> >>>> I haven't added any tickets to it yet. >> >>>> >> >>>> >> >>> This might deserve also nice Web UI checkbox similar to >> "Trusted for >> >>> delegation". CCing Pavel. >> >>> >> >> Here is patch with new checkbox. It is without ticket in >> commit message so >> >> once we will have the ticket I will send another patch >> witch updated commit >> >> message. >> > >> > https://fedorahosted.org/freeipa/newticket >> >> > >> > ;-) >> >> It's prerequisite for >> https://fedorahosted.org/freeipa/ticket/5764 >> so we >> might use that. >> >> > Please, add your answers at the end of the previous mail in the > future. > > Also, your patch raises pep8 errors: > ./ipaserver/plugins/xmlserver.py:31:80: E501 line too long (189 > > 79 characters) > ./ipaserver/rpcserver.py:885:5: E113 unexpected indentation > > Could you please fix them? > > > Hi, > > thanks for review Stanislav. I understand > ./ipaserver/rpcserver.py:885:5: E113 unexpected indentation, that is > my fault but really do not understand first one. Is there policy that > you decided not to patch existing files, even if there was obviously > longer line before patch until it is not necessary? > Anyway I hope it should be ok now. > > Thank you. There's a policy to try to be pep8 compliant as much as we can with any new patches. Your new patch would still raise some pep8 errors, please see the attached patch that should be ok. If it's ok with you then ACK, it seems to be working. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tdudlak-0001-4-Added-new-authentication-method.patch Type: text/x-patch Size: 2887 bytes Desc: not available URL: From slaznick at redhat.com Wed Aug 17 14:35:53 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 17 Aug 2016 16:35:53 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <20160817135854.e7wxvwfpfnoww26m@redhat.com> References: <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> <20160817135854.e7wxvwfpfnoww26m@redhat.com> Message-ID: On 08/17/2016 03:58 PM, Alexander Bokovoy wrote: > On Thu, 11 Aug 2016, Petr Vobornik wrote: >> On 08/11/2016 07:21 PM, Martin Basti wrote: >>> >>> >>> On 11.08.2016 18:57, Pavel Vomacka wrote: >>>> >>>> >>>> On 08/11/2016 02:00 PM, Petr Vobornik wrote: >>>>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >>>>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >>>>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >>>>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >>>>>>>>> Got it. One thing I would correct, though, -- don't use >>>>>>>>> kadmin.local, we >>>>>>>>> do support setting ok_as_delegate on the service principals >>>>>>>>> via IPA >>>>>>>>> CLI: >>>>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>>>>>>>> --ok-as-delegate=BOOL >>>>>>>>> Client credentials may be delegated to the >>>>>>>>> service >>>>>>>> I've tried >>>>>>>> >>>>>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >>>>>>>> >>>>>>>> but that does not seem to have the same effect as >>>>>>>> >>>>>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >>>>>>>> >>>>>>>> -- obtaining the delegated certificated fails. >>>>>>> That's because ok_as_delegate and ok_to_auth_as_delegate are >>>>>>> different >>>>>>> flags. >>>>>> Right. The following patch adds ok_to_auth_as_delegate to the >>>>>> service >>>>>> principal. >>>>>> >>>>>> I haven't added any tickets to it yet. >>>>>> >>>>>> >>>>> This might deserve also nice Web UI checkbox similar to "Trusted for >>>>> delegation". CCing Pavel. >>>>> >>>> Here is patch with new checkbox. It is without ticket in commit >>>> message so >>>> once we will have the ticket I will send another patch witch >>>> updated commit >>>> message. >>> >>> https://fedorahosted.org/freeipa/newticket >>> >>> ;-) >> >> It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 so we >> might use that. > Sounds good. Patch with updated commit message is attached. > > Thank you for the updated patch, works as expected so ACK. From slaznick at redhat.com Wed Aug 17 14:36:50 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 17 Aug 2016 16:36:50 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: <393a23e7-a4a5-63ac-2fe7-a81fa179f824@redhat.com> References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> <7352976a-17aa-7144-9952-dc9a3497801c@redhat.com> <393a23e7-a4a5-63ac-2fe7-a81fa179f824@redhat.com> Message-ID: On 08/17/2016 03:50 PM, Pavel Vomacka wrote: > > > > On 08/17/2016 02:42 PM, Pavel Vomacka wrote: >> >> >> On 08/11/2016 07:49 PM, Petr Vobornik wrote: >>> On 08/11/2016 07:21 PM, Martin Basti wrote: >>>> >>>> On 11.08.2016 18:57, Pavel Vomacka wrote: >>>>> >>>>> On 08/11/2016 02:00 PM, Petr Vobornik wrote: >>>>>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >>>>>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >>>>>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >>>>>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy >>>>>>>>> wrote: >>>>>>>>>> Got it. One thing I would correct, though, -- don't use >>>>>>>>>> kadmin.local, we >>>>>>>>>> do support setting ok_as_delegate on the service principals >>>>>>>>>> via IPA >>>>>>>>>> CLI: >>>>>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>>>>>>>>> --ok-as-delegate=BOOL >>>>>>>>>> Client credentials may be delegated >>>>>>>>>> to the >>>>>>>>>> service >>>>>>>>> I've tried >>>>>>>>> >>>>>>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >>>>>>>>> >>>>>>>>> but that does not seem to have the same effect as >>>>>>>>> >>>>>>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >>>>>>>>> >>>>>>>>> -- obtaining the delegated certificated fails. >>>>>>>> That's because ok_as_delegate and ok_to_auth_as_delegate are >>>>>>>> different >>>>>>>> flags. >>>>>>> Right. The following patch adds ok_to_auth_as_delegate to the >>>>>>> service >>>>>>> principal. >>>>>>> >>>>>>> I haven't added any tickets to it yet. >>>>>>> >>>>>>> >>>>>> This might deserve also nice Web UI checkbox similar to "Trusted for >>>>>> delegation". CCing Pavel. >>>>>> >>>>> Here is patch with new checkbox. It is without ticket in commit >>>>> message so >>>>> once we will have the ticket I will send another patch witch >>>>> updated commit >>>>> message. >>>> https://fedorahosted.org/freeipa/newticket >>>> >>>> ;-) >>> It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 >>> so we >>> might use that. >> Thank you, patch with updated commit message attached. >> >> >> > Attached patch adds checkbox also to host page. > Thank you, works as expected. ACK. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Aug 17 14:42:18 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Aug 2016 16:42:18 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: References: <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> <20160817135854.e7wxvwfpfnoww26m@redhat.com> Message-ID: On 17.8.2016 16:35, Stanislav Laznicka wrote: > On 08/17/2016 03:58 PM, Alexander Bokovoy wrote: >> On Thu, 11 Aug 2016, Petr Vobornik wrote: >>> On 08/11/2016 07:21 PM, Martin Basti wrote: >>>> >>>> >>>> On 11.08.2016 18:57, Pavel Vomacka wrote: >>>>> >>>>> >>>>> On 08/11/2016 02:00 PM, Petr Vobornik wrote: >>>>>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >>>>>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >>>>>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >>>>>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote: >>>>>>>>>> Got it. One thing I would correct, though, -- don't use >>>>>>>>>> kadmin.local, we >>>>>>>>>> do support setting ok_as_delegate on the service principals >>>>>>>>>> via IPA >>>>>>>>>> CLI: >>>>>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>>>>>>>>> --ok-as-delegate=BOOL >>>>>>>>>> Client credentials may be delegated to the >>>>>>>>>> service >>>>>>>>> I've tried >>>>>>>>> >>>>>>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >>>>>>>>> >>>>>>>>> but that does not seem to have the same effect as >>>>>>>>> >>>>>>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >>>>>>>>> >>>>>>>>> -- obtaining the delegated certificated fails. >>>>>>>> That's because ok_as_delegate and ok_to_auth_as_delegate are >>>>>>>> different >>>>>>>> flags. >>>>>>> Right. The following patch adds ok_to_auth_as_delegate to the >>>>>>> service >>>>>>> principal. >>>>>>> >>>>>>> I haven't added any tickets to it yet. >>>>>>> >>>>>>> >>>>>> This might deserve also nice Web UI checkbox similar to "Trusted for >>>>>> delegation". CCing Pavel. >>>>>> >>>>> Here is patch with new checkbox. It is without ticket in commit >>>>> message so >>>>> once we will have the ticket I will send another patch witch >>>>> updated commit >>>>> message. >>>> >>>> https://fedorahosted.org/freeipa/newticket >>>> >>>> ;-) >>> >>> It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 so we >>> might use that. >> Sounds good. Patch with updated commit message is attached. >> >> > Thank you for the updated patch, works as expected so ACK. Pushed to master: 1c73ac91a4c76cbada91f2b30d8b731b91af5195 -- Jan Cholasta From jcholast at redhat.com Wed Aug 17 14:42:35 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Aug 2016 16:42:35 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> <7352976a-17aa-7144-9952-dc9a3497801c@redhat.com> <393a23e7-a4a5-63ac-2fe7-a81fa179f824@redhat.com> Message-ID: <2089fe3f-f6ef-f7a2-a008-111de5eb065a@redhat.com> On 17.8.2016 16:36, Stanislav Laznicka wrote: > On 08/17/2016 03:50 PM, Pavel Vomacka wrote: >> >> >> >> On 08/17/2016 02:42 PM, Pavel Vomacka wrote: >>> >>> >>> On 08/11/2016 07:49 PM, Petr Vobornik wrote: >>>> On 08/11/2016 07:21 PM, Martin Basti wrote: >>>>> >>>>> On 11.08.2016 18:57, Pavel Vomacka wrote: >>>>>> >>>>>> On 08/11/2016 02:00 PM, Petr Vobornik wrote: >>>>>>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >>>>>>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >>>>>>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >>>>>>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy >>>>>>>>>> wrote: >>>>>>>>>>> Got it. One thing I would correct, though, -- don't use >>>>>>>>>>> kadmin.local, we >>>>>>>>>>> do support setting ok_as_delegate on the service principals >>>>>>>>>>> via IPA >>>>>>>>>>> CLI: >>>>>>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>>>>>>>>>> --ok-as-delegate=BOOL >>>>>>>>>>> Client credentials may be delegated >>>>>>>>>>> to the >>>>>>>>>>> service >>>>>>>>>> I've tried >>>>>>>>>> >>>>>>>>>> ipa service-mod --ok-as-delegate=True HTTP/$(hostname) >>>>>>>>>> >>>>>>>>>> but that does not seem to have the same effect as >>>>>>>>>> >>>>>>>>>> modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test >>>>>>>>>> >>>>>>>>>> -- obtaining the delegated certificated fails. >>>>>>>>> That's because ok_as_delegate and ok_to_auth_as_delegate are >>>>>>>>> different >>>>>>>>> flags. >>>>>>>> Right. The following patch adds ok_to_auth_as_delegate to the >>>>>>>> service >>>>>>>> principal. >>>>>>>> >>>>>>>> I haven't added any tickets to it yet. >>>>>>>> >>>>>>>> >>>>>>> This might deserve also nice Web UI checkbox similar to "Trusted for >>>>>>> delegation". CCing Pavel. >>>>>>> >>>>>> Here is patch with new checkbox. It is without ticket in commit >>>>>> message so >>>>>> once we will have the ticket I will send another patch witch >>>>>> updated commit >>>>>> message. >>>>> https://fedorahosted.org/freeipa/newticket >>>>> >>>>> ;-) >>>> It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 >>>> so we >>>> might use that. >>> Thank you, patch with updated commit message attached. >>> >>> >>> >> Attached patch adds checkbox also to host page. >> > Thank you, works as expected. ACK. Pushed to master: c36d721a01106e24186bd6b2f0fc74d7af31d5ba -- Jan Cholasta From ldoudova at redhat.com Wed Aug 17 14:45:58 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 17 Aug 2016 16:45:58 +0200 Subject: [Freeipa-devel] [PATCH 0035][Tests] Fix failing tests in test_ipalib/test_frontend Message-ID: <3d3baf1e-8b4f-19a5-02db-f8a6a3bdce72@redhat.com> Hi, attached patch provides fix for 2 out of three failing tests in ipatests/test_ipalib/test_frontend.py. Failures were caused by changes related to thin client implementation. Fix for the third failure will be provided later (after my PTO), as it will be more complicated fix. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0035-Tests-Fix-failing-tests-in-test_ipalib-test_frontend.patch Type: text/x-patch Size: 4264 bytes Desc: not available URL: From mkubik at redhat.com Wed Aug 17 14:49:10 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 17 Aug 2016 16:49:10 +0200 Subject: [Freeipa-devel] [PATCH 0034][Tests] Fix failing tests in test_ipalib/test_parameters In-Reply-To: <9cfbb09c-46fd-7178-c136-cf8d86c4da92@redhat.com> References: <9cfbb09c-46fd-7178-c136-cf8d86c4da92@redhat.com> Message-ID: <78e1cb0d-02b0-521f-8fa8-476f9d26ae56@redhat.com> On 08/17/2016 04:31 PM, Lenka Doudova wrote: > Hi, > > attached patch fixes part of failing tests in > ipatests/test_ipalib/test_parameters.py. Failures were caused mainly > by thin client feature, sometimes by usage of unicode, which tests did > not reflect. Issues were discussed with Honza. > > Remaining failing tests should be fixed in scope of one of Martin3's > future patches (namely failures described in > https://fedorahosted.org/freeipa/ticket/6190) > > Lenka > > > ACK -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Aug 17 14:56:51 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Aug 2016 16:56:51 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Added new authentication method In-Reply-To: References: <579F67F8.6020007@redhat.com> <20160802145738.6bajhge2pms5ukb6@redhat.com> <20160803064636.GR1586@redhat.com> <20160803072952.2ugaw5cfkd3fvntp@redhat.com> <20160804152755.GA4601@redhat.com> <0f06085f-123f-bb39-567a-7f7be6d5255f@redhat.com> <20160811085448.7dvj2btquzi4276s@redhat.com> <86d41c27-5350-8bfb-505d-9ab4153aa487@redhat.com> <2c35a975-2f44-1557-7770-cba7105e580c@redhat.com> <007f2f40-d9ac-0a3f-f891-ceb433f6e9e5@redhat.com> <3bbdc0ea-29b6-36d3-1631-adb9954d8924@redhat.com> <6d157c60-8658-70e4-2213-e3573fc19eac@redhat.com> Message-ID: <5b41c6f7-4c7a-45ae-e21b-6052f984b579@redhat.com> On 17.8.2016 16:33, Stanislav Laznicka wrote: > On 08/17/2016 04:11 PM, Tibor Dudlak wrote: >> >> On Wed, Aug 17, 2016 at 3:36 PM, Stanislav Laznicka >> > wrote: >> >> On 08/16/2016 03:16 PM, Tibor Dudlak wrote: >>> Hi, >>> >>> I have edited this patch after review. It should be okay now. >>> >>> Thank you. >>> >>> On Thu, Aug 11, 2016 at 7:49 PM, Petr Vobornik >>> > wrote: >>> >>> On 08/11/2016 07:21 PM, Martin Basti wrote: >>> > >>> > >>> > On 11.08.2016 18:57, Pavel Vomacka wrote: >>> >> >>> >> >>> >> On 08/11/2016 02:00 PM, Petr Vobornik wrote: >>> >>> On 08/11/2016 10:54 AM, Alexander Bokovoy wrote: >>> >>>> On Thu, 11 Aug 2016, Jan Cholasta wrote: >>> >>>>> On 4.8.2016 17:27, Jan Pazdziora wrote: >>> >>>>>> On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander >>> Bokovoy wrote: >>> >>>>>>> Got it. One thing I would correct, though, -- don't use >>> >>>>>>> kadmin.local, we >>> >>>>>>> do support setting ok_as_delegate on the service >>> principals via IPA >>> >>>>>>> CLI: >>> >>>>>>> $ ipa service-mod --help |grep -A1 ok-as-delegate >>> >>>>>>> --ok-as-delegate=BOOL >>> >>>>>>> Client credentials may be >>> delegated to the >>> >>>>>>> service >>> >>>>>> I've tried >>> >>>>>> >>> >>>>>> ipa service-mod --ok-as-delegate=True >>> HTTP/$(hostname) >>> >>>>>> >>> >>>>>> but that does not seem to have the same effect as >>> >>>>>> >>> >>>>>> modprinc +ok_to_auth_as_delegate >>> HTTP/ipa.example.test >>> >>>>>> >>> >>>>>> -- obtaining the delegated certificated fails. >>> >>>>> That's because ok_as_delegate and >>> ok_to_auth_as_delegate are different >>> >>>>> flags. >>> >>>> Right. The following patch adds ok_to_auth_as_delegate >>> to the service >>> >>>> principal. >>> >>>> >>> >>>> I haven't added any tickets to it yet. >>> >>>> >>> >>>> >>> >>> This might deserve also nice Web UI checkbox similar to >>> "Trusted for >>> >>> delegation". CCing Pavel. >>> >>> >>> >> Here is patch with new checkbox. It is without ticket in >>> commit message so >>> >> once we will have the ticket I will send another patch >>> witch updated commit >>> >> message. >>> > >>> > https://fedorahosted.org/freeipa/newticket >>> >>> > >>> > ;-) >>> >>> It's prerequisite for >>> https://fedorahosted.org/freeipa/ticket/5764 >>> so we >>> might use that. >>> >>> >> Please, add your answers at the end of the previous mail in the >> future. >> >> Also, your patch raises pep8 errors: >> ./ipaserver/plugins/xmlserver.py:31:80: E501 line too long (189 > >> 79 characters) >> ./ipaserver/rpcserver.py:885:5: E113 unexpected indentation >> >> Could you please fix them? >> >> >> Hi, >> >> thanks for review Stanislav. I understand >> ./ipaserver/rpcserver.py:885:5: E113 unexpected indentation, that is >> my fault but really do not understand first one. Is there policy that >> you decided not to patch existing files, even if there was obviously >> longer line before patch until it is not necessary? >> Anyway I hope it should be ok now. >> >> Thank you. > > There's a policy to try to be pep8 compliant as much as we can with any > new patches. Your new patch would still raise some pep8 errors, please > see the attached patch that should be ok. If it's ok with you then ACK, > it seems to be working. (16:54:22) pvoborni_: tdudlak: muzem pushnout tu standovu verzi tveho patche? (16:54:36) tdudlak: jasne (16:55:12) pvoborni_: jcholast: ^ Pushed to master: d25a0725c0e09891bd0df927641dac878dfe6a7d -- Jan Cholasta From mkubik at redhat.com Wed Aug 17 14:57:15 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 17 Aug 2016 16:57:15 +0200 Subject: [Freeipa-devel] [PATCH 0035][Tests] Fix failing tests in test_ipalib/test_frontend In-Reply-To: <3d3baf1e-8b4f-19a5-02db-f8a6a3bdce72@redhat.com> References: <3d3baf1e-8b4f-19a5-02db-f8a6a3bdce72@redhat.com> Message-ID: <0ceaadd5-d55f-9612-88ef-2d34657dece2@redhat.com> On 08/17/2016 04:45 PM, Lenka Doudova wrote: > Hi, > > attached patch provides fix for 2 out of three failing tests in > ipatests/test_ipalib/test_frontend.py. Failures were caused by changes > related to thin client implementation. > > Fix for the third failure will be provided later (after my PTO), as it > will be more complicated fix. > > Lenka > > > NACK: ************* Module ipatests.test_ipalib.test_frontend ipatests/test_ipalib/test_frontend.py:944: [E1120(no-value-for-parameter), test_Object.test_init.FakeAPI] No value for argument 'base' in constructor call) -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldoudova at redhat.com Wed Aug 17 15:08:45 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 17 Aug 2016 17:08:45 +0200 Subject: [Freeipa-devel] [PATCH 0035][Tests] Fix failing tests in test_ipalib/test_frontend In-Reply-To: <0ceaadd5-d55f-9612-88ef-2d34657dece2@redhat.com> References: <3d3baf1e-8b4f-19a5-02db-f8a6a3bdce72@redhat.com> <0ceaadd5-d55f-9612-88ef-2d34657dece2@redhat.com> Message-ID: <7130181a-a1a8-0619-99ed-da7323d907f2@redhat.com> On 08/17/2016 04:57 PM, Milan Kub?k wrote: > On 08/17/2016 04:45 PM, Lenka Doudova wrote: >> Hi, >> >> attached patch provides fix for 2 out of three failing tests in >> ipatests/test_ipalib/test_frontend.py. Failures were caused by >> changes related to thin client implementation. >> >> Fix for the third failure will be provided later (after my PTO), as >> it will be more complicated fix. >> >> Lenka >> >> >> > > NACK: > > ************* Module ipatests.test_ipalib.test_frontend > ipatests/test_ipalib/test_frontend.py:944: > [E1120(no-value-for-parameter), test_Object.test_init.FakeAPI] No > value for argument 'base' in constructor call) > > -- > Milan Kubik Oh sorry, I attached non-updated patch... Correct one attached now. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0035-2-Tests-Fix-failing-tests-in-test_ipalib-test_frontend.patch Type: text/x-patch Size: 3673 bytes Desc: not available URL: From mkubik at redhat.com Wed Aug 17 15:12:08 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 17 Aug 2016 17:12:08 +0200 Subject: [Freeipa-devel] [PATCH 0035][Tests] Fix failing tests in test_ipalib/test_frontend In-Reply-To: <7130181a-a1a8-0619-99ed-da7323d907f2@redhat.com> References: <3d3baf1e-8b4f-19a5-02db-f8a6a3bdce72@redhat.com> <0ceaadd5-d55f-9612-88ef-2d34657dece2@redhat.com> <7130181a-a1a8-0619-99ed-da7323d907f2@redhat.com> Message-ID: On 08/17/2016 05:08 PM, Lenka Doudova wrote: > > > > On 08/17/2016 04:57 PM, Milan Kub?k wrote: >> On 08/17/2016 04:45 PM, Lenka Doudova wrote: >>> Hi, >>> >>> attached patch provides fix for 2 out of three failing tests in >>> ipatests/test_ipalib/test_frontend.py. Failures were caused by >>> changes related to thin client implementation. >>> >>> Fix for the third failure will be provided later (after my PTO), as >>> it will be more complicated fix. >>> >>> Lenka >>> >>> >>> >> >> NACK: >> >> ************* Module ipatests.test_ipalib.test_frontend >> ipatests/test_ipalib/test_frontend.py:944: >> [E1120(no-value-for-parameter), test_Object.test_init.FakeAPI] No >> value for argument 'base' in constructor call) >> >> -- >> Milan Kubik > Oh sorry, I attached non-updated patch... > Correct one attached now. > > Lenka Thanks for the work. ACK -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Wed Aug 17 15:25:54 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 17 Aug 2016 17:25:54 +0200 Subject: [Freeipa-devel] [PATCH 0215-0216] Child domain fixes for AD trust In-Reply-To: <20160808112722.ldzcfmfpdzzmumex@redhat.com> References: <20160808112722.ldzcfmfpdzzmumex@redhat.com> Message-ID: <36addf67-0223-b8a5-9aa5-9519f9e2c0ec@redhat.com> On 08/08/2016 01:27 PM, Alexander Bokovoy wrote: > Hi! > > Attached two patches attempt to fix some of the issues we see with child > domains. > > SSSD only 'sees' users from child domains if there is an ID range for > each of them. However, after refactoring of trust code when external > trust was introduced, part of the range creation had wrong assumption > that if a trusted domain exists, its range also exists. This is now > fixed to try to create range even if the domain exists. In fact, because > the older code was not going to the range creation for trusted domains > which already existed, adding ranges was done incorrectly: ID ranges use > full domain name and don't need - hierarchy, but the code > was passing both parent and the child names. As result, an attempt to > create an ID range for parent was done instead of the child. Parent ID > range already existed so we never got to create child ID ranges at all > in that case. > > Finally, there is a fix in SSSD to properly generate CA paths so that > libkrb5 can calculate correct trust path via forest root (parent) > domain. While looking at that, I also decided to simplify logic in > ipa-kdb driver because for cross-forest trust we never can transit to > the child domain directly, we always have to use the forest root domain. > However, old code could actually set a immediate domain's parent instead > of the forest root for deep level trust relationship within the forest > we trust. As we still cannot get to second level or beyond directly or > via their actual parent domain, we always have to go through the forest > root domain. The simplified code enforces this logic. > > > > ACK, but patch 215 needs rebase for ipa-4-3 and ipa-4-2. -- Martin^3 Babinsky From mbasti at redhat.com Wed Aug 17 15:40:20 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 17 Aug 2016 17:40:20 +0200 Subject: [Freeipa-devel] [PATCH 0034][Tests] Fix failing tests in test_ipalib/test_parameters In-Reply-To: <78e1cb0d-02b0-521f-8fa8-476f9d26ae56@redhat.com> References: <9cfbb09c-46fd-7178-c136-cf8d86c4da92@redhat.com> <78e1cb0d-02b0-521f-8fa8-476f9d26ae56@redhat.com> Message-ID: <4877eeb8-aa33-043f-d569-c20d40836ea7@redhat.com> On 17.08.2016 16:49, Milan Kub?k wrote: > On 08/17/2016 04:31 PM, Lenka Doudova wrote: >> Hi, >> >> attached patch fixes part of failing tests in >> ipatests/test_ipalib/test_parameters.py. Failures were caused mainly >> by thin client feature, sometimes by usage of unicode, which tests >> did not reflect. Issues were discussed with Honza. >> >> Remaining failing tests should be fixed in scope of one of Martin3's >> future patches (namely failures described in >> https://fedorahosted.org/freeipa/ticket/6190) >> >> Lenka >> >> >> > ACK > > > -- > Milan Kubik > > Pushed to master: 380ffcc052c561084d0ef3f65f379bc762d9a326 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Aug 17 15:43:18 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 17 Aug 2016 17:43:18 +0200 Subject: [Freeipa-devel] [PATCH 0035][Tests] Fix failing tests in test_ipalib/test_frontend In-Reply-To: References: <3d3baf1e-8b4f-19a5-02db-f8a6a3bdce72@redhat.com> <0ceaadd5-d55f-9612-88ef-2d34657dece2@redhat.com> <7130181a-a1a8-0619-99ed-da7323d907f2@redhat.com> Message-ID: <7884ff14-e5ac-7312-dbc3-913dc154247c@redhat.com> On 17.08.2016 17:12, Milan Kub?k wrote: > On 08/17/2016 05:08 PM, Lenka Doudova wrote: >> >> >> >> On 08/17/2016 04:57 PM, Milan Kub?k wrote: >>> On 08/17/2016 04:45 PM, Lenka Doudova wrote: >>>> Hi, >>>> >>>> attached patch provides fix for 2 out of three failing tests in >>>> ipatests/test_ipalib/test_frontend.py. Failures were caused by >>>> changes related to thin client implementation. >>>> >>>> Fix for the third failure will be provided later (after my PTO), as >>>> it will be more complicated fix. >>>> >>>> Lenka >>>> >>>> >>>> >>> >>> NACK: >>> >>> ************* Module ipatests.test_ipalib.test_frontend >>> ipatests/test_ipalib/test_frontend.py:944: >>> [E1120(no-value-for-parameter), test_Object.test_init.FakeAPI] No >>> value for argument 'base' in constructor call) >>> >>> -- >>> Milan Kubik >> Oh sorry, I attached non-updated patch... >> Correct one attached now. >> >> Lenka > > Thanks for the work. ACK > > -- > Milan Kubik > > Pushed to master: 44a2bdd8ead48b33b23bfb1e1f71027e5cfc5f04 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajat.linux at gmail.com Thu Aug 18 07:48:59 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Thu, 18 Aug 2016 09:48:59 +0200 Subject: [Freeipa-devel] pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ilt-gif-ipa01.ipa.preprod.local user=aduser@corp.addomain.com In-Reply-To: <20160816124614.dnoqxpzw6gsvblo6@redhat.com> References: <20160816124614.dnoqxpzw6gsvblo6@redhat.com> Message-ID: Thanks. When i am trying to accesses user with password i am getting below message in logs. *Aug 18 09:38:17 ilt-gif-ipa02 [sssd[krb5_child[8505]]]: Cannot find KDC for realm "ADDOMAON.COM "* when i connect through ssh, it tries to contact the KDC for the realm *ADDOMAON.COM * which should be corp.addomain.com Do you have any further comments or suggestions that may help us. /Rajat On Tue, Aug 16, 2016 at 2:46 PM, Alexander Bokovoy wrote: > On Tue, 16 Aug 2016, rajat gupta wrote: > >> Hi, >> >> >> I have done IPA AD trust between IPA and AD server. But trust is showing >> offline always. But we are able to get the AD user information. And able >> to >> grant the KRB ticket. >> >> >> >> # wbinfo --online-status >> BUILTIN : online >> IPA : online >> *CORP : offline* >> > Don't use wbinfo. Its output is irrelevant starting from FreeIPA 3.3. > > >> >> #id aduser at CORP.ADDOMAIN.COM >> uid=1007656917(aduser at corp.addomain.com) gid=1007656917( >> aduser at corp.addomain.com) groups=1007656917(aduser at corp.addomain.com >> ),1007715891(prg-msoffice2013pro(kms)@corp.addomain.com),1007663829( >> da-eeg-intra-read at corp.addomain.com),1007600513(domain >> users at corp.addomain.com) >> >> >> [root at ilt-gif-ipa01 ~]# kinit aduser at CORP.ADDOMAIN.COM >> Password for aduser at CORP.ADDOMAIN.COM: >> [root at ilt-gif-ipa01 ~]# >> [root at ilt-gif-ipa01 ~]# >> [root at ilt-gif-ipa01 ~]# klist >> Ticket cache: KEYRING:persistent:0:0 >> Default principal: aduser at CORP.ADDOMAIN.COM >> >> Valid starting Expires Service principal >> 08/11/2016 13:11:35 08/11/2016 23:11:35 krbtgt/ >> CORP.ADDOMAIN.COM at CORP.ADDOMAIN.COM >> renew until 08/12/2016 13:11:29 >> [root at ilt-gif-ipa01 ~]# >> > This is irrelevant for the trust case because you are authenticating > against AD DCs, not IPA KDCs. > > >> >> >> Form IPA client server we are able to get the all thinks ( KRB ticket/ >> user/groups ) >> >> [root at ilt-gif-ipa02 ~]# getent passwd aduser at CORP.addomain.COM >> aduser at corp.addomain.com:*:1007656917:1007656917:USER NAME:/home/ >> corp.addomain.com/aduser: >> [root at ilt-gif-ipa02 ~]# >> >> >> [root at ilt-gif-ipa02 ~]# getent group aduser at CORP.addomain.COM >> aduser at corp.addomain.com:*:1007656917: >> [root at ilt-gif-ipa02 ~]# >> >> >> [root at ilt-gif-ipa02 ~]# id aduser at CORP.addomain.COM >> uid=1007656917(aduser at corp.addomain.com) gid=1007656917( >> aduser at corp.addomain.com) groups=1007656917(aduser at corp.addomain.com >> ),1007715891(prg-msoffice2013pro(kms)@corp.addomain.com),1007663829( >> da-eeg-intra-read at corp.addomain.com),1007600513(domain >> users at corp.addomain.com),1007725088(tfs_users at corp.addomain.com) >> >> >> Also we are to ssh to IPA client on same machine or from some other >> machine with gss authentication. But using password authentication it?s >> failed to login. >> >> *ERROR:- pam_sss(sshd:auth): authentication failure; logname* >> >> >> >> kinit aduser at CORP.ADDOMAIN.COM >> Password for aduser at CORP.ADDOMAIN.COM: >> >> >> >> [root at ilt-gif-ipa02 ~]# ssh -vl aduser at corp.addomain.com >> ilt-gif-ipa02.ipa.preprod.local >> OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013 >> debug1: Reading configuration data /etc/ssh/ssh_config >> debug1: /etc/ssh/ssh_config line 60: Applying options for * >> debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p >> 22 ilt-gif-ipa02.ipa.preprod.local >> debug1: permanently_set_uid: 0/0 >> debug1: permanently_drop_suid: 0 >> debug1: identity file /root/.ssh/id_rsa type -1 >> debug1: identity file /root/.ssh/id_rsa-cert type -1 >> debug1: identity file /root/.ssh/id_dsa type -1 >> debug1: identity file /root/.ssh/id_dsa-cert type -1 >> debug1: identity file /root/.ssh/id_ecdsa type -1 >> debug1: identity file /root/.ssh/id_ecdsa-cert type -1 >> debug1: identity file /root/.ssh/id_ed25519 type -1 >> debug1: identity file /root/.ssh/id_ed25519-cert type -1 >> debug1: Enabling compatibility mode for protocol 2.0 >> debug1: Local version string SSH-2.0-OpenSSH_6.6.1 >> debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 >> debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 >> debug1: SSH2_MSG_KEXINIT sent >> debug1: SSH2_MSG_KEXINIT received >> debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none >> debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none >> debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 >> debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 >> debug1: sending SSH2_MSG_KEX_ECDH_INIT >> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY >> debug1: Server host key: ECDSA >> f0:e6:b2:66:c8:41:06:4e:83:a4:a2:c5:5a:57:24:66 >> debug1: Host 'ilt-gif-ipa02.ipa.preprod.local' is known and matches the >> ECDSA host key. >> debug1: Found key in /root/.ssh/known_hosts:3 >> debug1: ssh_ecdsa_verify: signature correct >> debug1: SSH2_MSG_NEWKEYS sent >> debug1: expecting SSH2_MSG_NEWKEYS >> debug1: SSH2_MSG_NEWKEYS received >> debug1: SSH2_MSG_SERVICE_REQUEST sent >> debug1: SSH2_MSG_SERVICE_ACCEPT received >> debug1: Authentications that can continue: >> publickey,gssapi-keyex,gssapi-with-mic,password >> debug1: Next authentication method: gssapi-keyex >> debug1: No valid Key exchange context >> debug1: Next authentication method: gssapi-with-mic >> *debug1: Authentication succeeded (gssapi-with-mic).* >> Authenticated to ilt-gif-ipa02.ipa.preprod.local (via proxy). >> debug1: channel 0: new [client-session] >> debug1: Requesting no-more-sessions at openssh.com >> debug1: Entering interactive session. >> debug1: Sending environment. >> debug1: Sending env LANG = en_US.UTF-8 >> Last login: Thu Aug 11 13:17:05 2016 from ilt-gif-ipa02.ipa.preprod.local >> >> RHN kickstart on 2014-10-16 >> >> -sh-4.2$ pwd >> /home/corp.addomain.com/aduser >> -sh-4.2$ who am i >> aduser at corp.addomain.com pts/3 2016-08-11 13:19 >> (ilt-gif-ipa02.ipa.preprod.local) >> -sh-4.2$ >> >> >> >> ]# ssh aduser at corp.addomain.com@ilt-gif-ipa02.ipa.preprod.local >> e600336 at corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password: >> Permission denied, please try again. >> e600336 at corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password: >> >> >> Can you please help me i am not able to login with AD user >> password authentication. >> > If you cannot login with password but can with Kerberos credentials, you > need to look into SSSD logs on the ilt-gif-ipa02.ipa.preprod.local host. > See https://fedorahosted.org/sssd/wiki/Troubleshooting > > > -- > / Alexander Bokovoy > -- *Rajat Gupta * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Aug 18 08:08:42 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 18 Aug 2016 10:08:42 +0200 Subject: [Freeipa-devel] [PATCH 689] tests: fix test_ipalib.test_frontend.test_Object Message-ID: <1fe5fa22-8162-e8cb-b5a9-14373488c19f@redhat.com> SSIA -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-689-tests-fix-test_ipalib.test_frontend.test_Object.patch Type: text/x-patch Size: 1830 bytes Desc: not available URL: From jhrozek at redhat.com Thu Aug 18 08:31:54 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 18 Aug 2016 10:31:54 +0200 Subject: [Freeipa-devel] pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ilt-gif-ipa01.ipa.preprod.local user=aduser@corp.addomain.com In-Reply-To: References: <20160816124614.dnoqxpzw6gsvblo6@redhat.com> Message-ID: <20160818083154.GF20350@hendrix> On Thu, Aug 18, 2016 at 09:48:59AM +0200, rajat gupta wrote: > Thanks. > > When i am trying to accesses user with password i am getting below message > in logs. > > *Aug 18 09:38:17 ilt-gif-ipa02 [sssd[krb5_child[8505]]]: Cannot find KDC > for realm "ADDOMAON.COM "* > > when i connect through ssh, it tries to contact the KDC for the realm > *ADDOMAON.COM > * > > which should be corp.addomain.com > > > Do you have any further comments or suggestions that may help us. Can we see the sssd logs as requested before please? https://fedorahosted.org/sssd/wiki/Troubleshooting From pspacek at redhat.com Thu Aug 18 08:56:05 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Aug 2016 10:56:05 +0200 Subject: [Freeipa-devel] [PATCH 689] tests: fix test_ipalib.test_frontend.test_Object In-Reply-To: <1fe5fa22-8162-e8cb-b5a9-14373488c19f@redhat.com> References: <1fe5fa22-8162-e8cb-b5a9-14373488c19f@redhat.com> Message-ID: <9d8daae0-cf0e-cd5a-4868-1afb7052ebc9@redhat.com> On 18.8.2016 10:08, Jan Cholasta wrote: > SSIA Could you add one sentence or a link to a ticket which forced this change? When reading the patch, I have no way to say why the change is necessary - so it is impossible to verify correctness. (Sure, the test will pass, but I have no way to distinguish incorrect test passing on incorrect implementation vs. correct test passing on correct implementation.) -- Petr^2 Spacek From mbasti at redhat.com Thu Aug 18 09:01:02 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 18 Aug 2016 11:01:02 +0200 Subject: [Freeipa-devel] [PATCH 689] tests: fix test_ipalib.test_frontend.test_Object In-Reply-To: <9d8daae0-cf0e-cd5a-4868-1afb7052ebc9@redhat.com> References: <1fe5fa22-8162-e8cb-b5a9-14373488c19f@redhat.com> <9d8daae0-cf0e-cd5a-4868-1afb7052ebc9@redhat.com> Message-ID: <3f502fcd-6b1a-4de0-4292-2561f707aa4a@redhat.com> On 18.08.2016 10:56, Petr Spacek wrote: > On 18.8.2016 10:08, Jan Cholasta wrote: >> SSIA > Could you add one sentence or a link to a ticket which forced this change? > > When reading the patch, I have no way to say why the change is necessary - so > it is impossible to verify correctness. (Sure, the test will pass, but I have > no way to distinguish incorrect test passing on incorrect implementation vs. > correct test passing on correct implementation.) > +1 and add there this link also https://fedorahosted.org/freeipa/ticket/6188 From dkupka at redhat.com Thu Aug 18 09:06:01 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 18 Aug 2016 11:06:01 +0200 Subject: [Freeipa-devel] [PATCH 0112-7] Speeding up cli help In-Reply-To: References: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> <01ff40a4-b964-4f78-33dd-f1c92c490fdd@redhat.com> <29310e45-fc18-52fc-1686-651bb42480c9@redhat.com> <547fcaaa-c86c-f547-c049-2de82df78de8@redhat.com> <1ff6376d-e47b-cceb-0661-c66f2e3e4133@redhat.com> Message-ID: <369a1614-7c72-de53-99a3-28b20bb76682@redhat.com> On 17/08/16 14:17, Jan Cholasta wrote: > On 17.8.2016 13:21, David Kupka wrote: >> On 08/08/16 13:26, Jan Cholasta wrote: >>> On 4.8.2016 16:32, David Kupka wrote: >>>> On 03/08/16 16:33, Jan Cholasta wrote: >>>>> On 3.8.2016 16:23, David Kupka wrote: >>>>>> On 21/07/16 10:12, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 20.7.2016 14:32, David Kupka wrote: >>>>>>>> On 15/07/16 12:53, David Kupka wrote: >>>>>>>>> Hello! >>>>>>>>> >>>>>>>>> After Honza introduced thin client that builds plugins and >>>>>>>>> commands >>>>>>>>> dynamically from schema client became much slower. This is only >>>>>>>>> logical, >>>>>>>>> instead of importing a module client now must fetch the schema >>>>>>>>> from >>>>>>>>> server, parse it and instantiate the commands using the data. >>>>>>>>> >>>>>>>>> First step to speed it up was addition of schema cache to client. >>>>>>>>> That >>>>>>>>> removed the RTT and download time of fetching schema every time. >>>>>>>>> >>>>>>>>> Now the most time consuming task became displaying help for >>>>>>>>> lists of >>>>>>>>> topics and command and displaying individual topics. This is >>>>>>>>> simply >>>>>>>>> because of the need to instantiate all the commands to find the >>>>>>>>> relations between topics and commands. >>>>>>>>> >>>>>>>>> All the necessary bits for server commands and topics are >>>>>>>>> already in >>>>>>>>> the >>>>>>>>> schema cache so we can skip this part and generate help from it, >>>>>>>>> right? >>>>>>>>> Not so fast! >>>>>>>>> >>>>>>>>> There are client plugins with commands and topics. So we can >>>>>>>>> generate >>>>>>>>> basic bits (list of all topics, list of all commands, list of >>>>>>>>> commands >>>>>>>>> for each topic) from schema and store it in cache. Then we need >>>>>>>>> to go >>>>>>>>> through all client plugins and get similar bits for client >>>>>>>>> plugins. >>>>>>>>> Then >>>>>>>>> we can merge and print. >>>>>>>>> >>>>>>>>> Still the client response is not as fast as before and I this it >>>>>>>>> even >>>>>>>>> can't be. Also first time you display particular topic or list >>>>>>>>> takes >>>>>>>>> longer because it must be freshly generated and stored in cache >>>>>>>>> for >>>>>>>>> next >>>>>>>>> use. And this is what the attached patches do. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/6048 >>>>>>>> >>>>>>>> Reimplemented so there is no need to distinguish client plugins and >>>>>>>> remote plugins. >>>>>>>> The main idea of this approach is to avoid creating instances of >>>>>>>> the >>>>>>>> commands just to get the information about topic, name and summary >>>>>>>> needed for displaying help. Instead class properties are used to >>>>>>>> access >>>>>>>> the information directly in schema. >>>>>>> >>>>>>> Patch 0112: >>>>>>> >>>>>>> I think this would better be done in Schema.read_namespace_member, >>>>>>> because Schema is where all the state is. >>>>>>> >>>>>>> (BTW does _SchemaNameSpace.__getitem__ raise KeyError for >>>>>>> non-existent >>>>>>> keys? It looks like it doesn't.) >>>>>>> >>>>>>> >>>>>>> Patch 0113: >>>>>>> >>>>>>> How about setting _schema_cached to False in Schema.__init__() >>>>>>> rather >>>>>>> that getattr()-ing it in _ensure_cached()? >>>>>>> >>>>>>> >>>>>>> Patch 0116: >>>>>>> >>>>>>> ClientCommand.doc should be a class property as well, otherwise >>>>>>> .summary >>>>>>> won't work on it correctly. >>>>>>> >>>>>>> _SchemaCommand.doc should not be a property, as it's not needed for >>>>>>> .summary to work on it correctly. >>>>>>> >>>>>>> >>>>>>> Otherwise works fine for me. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> Updated patches attached. >>>>> >>>>> Thanks, ACK. >>>>> >>>>> Pushed to master: 229e2a1ed9ea9877cb5e879fadd99f9040f77c96 >>>>> >>>> >>>> I've made and reviewer overlooked some errors. Attached patches fix >>>> them. >>> >>> Shame on me. >>> >>> Anyway, >>> >>> 1) When schema() raises SchemaUpToDate, the current code explodes: >>> >>> ipa: ERROR: KeyError: 'fingerprint' >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1348, in >>> run >>> api.finalize() >>> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 707, >>> in finalize >>> self.__do_if_not_done('load_plugins') >>> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 422, >>> in __do_if_not_done >>> getattr(self, name)() >>> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 585, >>> in load_plugins >>> for package in self.packages: >>> File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 919, >>> in packages >>> ipaclient.remote_plugins.get_package(self), >>> File >>> "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", >>> line 92, in get_package >>> plugins = schema.get_package(api, server_info, client) >>> File >>> "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", >>> line 558, in get_package >>> fingerprint = str(schema['fingerprint']) >>> File >>> "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", >>> line 483, in __getitem__ >>> return self._dict[key] >>> KeyError: 'fingerprint' >>> >>> >>> 2) We read server info every time get_package() is called. It should be >>> cache similarly to how the schema is cached in the api object. >>> >>> >>> 3) Some of the commands are still fully initialized during "ipa help >>> commands". >>> >>> >>> Honza >>> >> Updated patches attached. > > Thanks, ACK. > > Pushed to master: 6e6cbda036559e741ead0ab5ba18b0be0b41621e > When locale is not available setlocale() explodes. Handling this exception in the same way as in ipalib/rpc.py to behave consistently. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0129.1-schema-cache-Fallback-to-en_us-when-locale-is-not-av.patch Type: text/x-patch Size: 1328 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 18 10:04:17 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 18 Aug 2016 12:04:17 +0200 Subject: [Freeipa-devel] [PATCH 0562] Fix: container owner should be able to add vault Message-ID: https://fedorahosted.org/freeipa/ticket/6159 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0562-Fix-container-owner-should-be-able-to-add-vault.patch Type: text/x-patch Size: 1163 bytes Desc: not available URL: From jcholast at redhat.com Thu Aug 18 10:13:10 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 18 Aug 2016 12:13:10 +0200 Subject: [Freeipa-devel] [PATCH 0112-7] Speeding up cli help In-Reply-To: <369a1614-7c72-de53-99a3-28b20bb76682@redhat.com> References: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> <01ff40a4-b964-4f78-33dd-f1c92c490fdd@redhat.com> <29310e45-fc18-52fc-1686-651bb42480c9@redhat.com> <547fcaaa-c86c-f547-c049-2de82df78de8@redhat.com> <1ff6376d-e47b-cceb-0661-c66f2e3e4133@redhat.com> <369a1614-7c72-de53-99a3-28b20bb76682@redhat.com> Message-ID: <98738fb1-5249-e069-d2cd-31948bd545b1@redhat.com> On 18.8.2016 11:06, David Kupka wrote: > On 17/08/16 14:17, Jan Cholasta wrote: >> On 17.8.2016 13:21, David Kupka wrote: >>> On 08/08/16 13:26, Jan Cholasta wrote: >>>> On 4.8.2016 16:32, David Kupka wrote: >>>>> On 03/08/16 16:33, Jan Cholasta wrote: >>>>>> On 3.8.2016 16:23, David Kupka wrote: >>>>>>> On 21/07/16 10:12, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 20.7.2016 14:32, David Kupka wrote: >>>>>>>>> On 15/07/16 12:53, David Kupka wrote: >>>>>>>>>> Hello! >>>>>>>>>> >>>>>>>>>> After Honza introduced thin client that builds plugins and >>>>>>>>>> commands >>>>>>>>>> dynamically from schema client became much slower. This is only >>>>>>>>>> logical, >>>>>>>>>> instead of importing a module client now must fetch the schema >>>>>>>>>> from >>>>>>>>>> server, parse it and instantiate the commands using the data. >>>>>>>>>> >>>>>>>>>> First step to speed it up was addition of schema cache to client. >>>>>>>>>> That >>>>>>>>>> removed the RTT and download time of fetching schema every time. >>>>>>>>>> >>>>>>>>>> Now the most time consuming task became displaying help for >>>>>>>>>> lists of >>>>>>>>>> topics and command and displaying individual topics. This is >>>>>>>>>> simply >>>>>>>>>> because of the need to instantiate all the commands to find the >>>>>>>>>> relations between topics and commands. >>>>>>>>>> >>>>>>>>>> All the necessary bits for server commands and topics are >>>>>>>>>> already in >>>>>>>>>> the >>>>>>>>>> schema cache so we can skip this part and generate help from it, >>>>>>>>>> right? >>>>>>>>>> Not so fast! >>>>>>>>>> >>>>>>>>>> There are client plugins with commands and topics. So we can >>>>>>>>>> generate >>>>>>>>>> basic bits (list of all topics, list of all commands, list of >>>>>>>>>> commands >>>>>>>>>> for each topic) from schema and store it in cache. Then we need >>>>>>>>>> to go >>>>>>>>>> through all client plugins and get similar bits for client >>>>>>>>>> plugins. >>>>>>>>>> Then >>>>>>>>>> we can merge and print. >>>>>>>>>> >>>>>>>>>> Still the client response is not as fast as before and I this it >>>>>>>>>> even >>>>>>>>>> can't be. Also first time you display particular topic or list >>>>>>>>>> takes >>>>>>>>>> longer because it must be freshly generated and stored in cache >>>>>>>>>> for >>>>>>>>>> next >>>>>>>>>> use. And this is what the attached patches do. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6048 >>>>>>>>> >>>>>>>>> Reimplemented so there is no need to distinguish client plugins >>>>>>>>> and >>>>>>>>> remote plugins. >>>>>>>>> The main idea of this approach is to avoid creating instances of >>>>>>>>> the >>>>>>>>> commands just to get the information about topic, name and summary >>>>>>>>> needed for displaying help. Instead class properties are used to >>>>>>>>> access >>>>>>>>> the information directly in schema. >>>>>>>> >>>>>>>> Patch 0112: >>>>>>>> >>>>>>>> I think this would better be done in Schema.read_namespace_member, >>>>>>>> because Schema is where all the state is. >>>>>>>> >>>>>>>> (BTW does _SchemaNameSpace.__getitem__ raise KeyError for >>>>>>>> non-existent >>>>>>>> keys? It looks like it doesn't.) >>>>>>>> >>>>>>>> >>>>>>>> Patch 0113: >>>>>>>> >>>>>>>> How about setting _schema_cached to False in Schema.__init__() >>>>>>>> rather >>>>>>>> that getattr()-ing it in _ensure_cached()? >>>>>>>> >>>>>>>> >>>>>>>> Patch 0116: >>>>>>>> >>>>>>>> ClientCommand.doc should be a class property as well, otherwise >>>>>>>> .summary >>>>>>>> won't work on it correctly. >>>>>>>> >>>>>>>> _SchemaCommand.doc should not be a property, as it's not needed for >>>>>>>> .summary to work on it correctly. >>>>>>>> >>>>>>>> >>>>>>>> Otherwise works fine for me. >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>>> Updated patches attached. >>>>>> >>>>>> Thanks, ACK. >>>>>> >>>>>> Pushed to master: 229e2a1ed9ea9877cb5e879fadd99f9040f77c96 >>>>>> >>>>> >>>>> I've made and reviewer overlooked some errors. Attached patches fix >>>>> them. >>>> >>>> Shame on me. >>>> >>>> Anyway, >>>> >>>> 1) When schema() raises SchemaUpToDate, the current code explodes: >>>> >>>> ipa: ERROR: KeyError: 'fingerprint' >>>> Traceback (most recent call last): >>>> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1348, in >>>> run >>>> api.finalize() >>>> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 707, >>>> in finalize >>>> self.__do_if_not_done('load_plugins') >>>> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 422, >>>> in __do_if_not_done >>>> getattr(self, name)() >>>> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 585, >>>> in load_plugins >>>> for package in self.packages: >>>> File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 919, >>>> in packages >>>> ipaclient.remote_plugins.get_package(self), >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", >>>> >>>> line 92, in get_package >>>> plugins = schema.get_package(api, server_info, client) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", >>>> line 558, in get_package >>>> fingerprint = str(schema['fingerprint']) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", >>>> line 483, in __getitem__ >>>> return self._dict[key] >>>> KeyError: 'fingerprint' >>>> >>>> >>>> 2) We read server info every time get_package() is called. It should be >>>> cache similarly to how the schema is cached in the api object. >>>> >>>> >>>> 3) Some of the commands are still fully initialized during "ipa help >>>> commands". >>>> >>>> >>>> Honza >>>> >>> Updated patches attached. >> >> Thanks, ACK. >> >> Pushed to master: 6e6cbda036559e741ead0ab5ba18b0be0b41621e >> > > When locale is not available setlocale() explodes. Handling this > exception in the same way as in ipalib/rpc.py to behave consistently. Works for me, ACK. Pushed to master: b6d5ed139b261b5db078ab652d22ea1d3b8092d3 -- Jan Cholasta From mbasti at redhat.com Thu Aug 18 11:04:16 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 18 Aug 2016 13:04:16 +0200 Subject: [Freeipa-devel] [PATCH 0562] Fix: container owner should be able to add vault In-Reply-To: References: Message-ID: On 18.08.2016 12:04, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/6159 > > > Patch attached. > > > Pushed to master: 6b7d6417d403c983691c790c1e60cfe32bf1c420 Pushed under oneliner rule -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Thu Aug 18 11:25:22 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 18 Aug 2016 13:25:22 +0200 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: <20160817112037.phvkgo3zbw55gujk@redhat.com> References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> <20160817112037.phvkgo3zbw55gujk@redhat.com> Message-ID: On 08/17/2016 01:20 PM, Alexander Bokovoy wrote: > On Wed, 17 Aug 2016, Martin Babinsky wrote: >> Hi Alexander, >> >> patch 207: LGTM, but I have a feeling that the patch should be linked >> to both #6021 and #6076 so that it is not lost during backports. >> >> patch 218: >> >> ipalib/errors.py: >> >> 1.) >> I'm not sure if TrustTopologyConflictError should inherit from >> InvocationError. The semantics of InvocationError implies that >> something was wrong when trying to invoke the command (a param failed >> to validate/convert, incorrect number of args, etc.), while this is >> more of an exception during command execution (no. and type of params >> was correct, command started to execute but encountered an error >> condition). Thus I think it should inherit from ExecutionError. CC'ing >> Jan for more thoughts on this. > Using ExecutionError would work to me too, as long as we display the > error to a user. >> Why is TrustTopologyConflictSolved listed amogn public errors? Since >> it is used only in dcerpc.py to restart trust establishment after >> resolving conflicts, it should be a private exception in dcerpc.py for >> this purpose. > I originally wanted to make it a warning -- i.e. if we fixed the > conflict, return the result and show the warning that we did solve the > conflict. After all, the code is modifying another trusted forest's > topology on behalf of the user. I can move the error class to dcerpc.py > > >> 3.) >> Also please split the exception format string like this so that the >> line is not too long (there is not much we can do about doctest so >> leave that line as it is): >> >> @@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): >> """ >> >> errno = 3017 >> - format = _("Forest '%(forest)s' has existing trust to forest(s) >> %(domains)s which prevents a trust to '%(conflict)s'") >> + format = _("Forest '%(forest)s' has existing trust to forest(s) " >> + "%(domains)s which prevents a trust to '%(conflict)s'") >> >> Do not worry about gettext, it can handle it just fine, there are >> plenty of examples in server plugins, for example. > Done. > >> ipaserver/dcerpc.py: >> >> 1.) >> >> I think that instead of returning result and raising >> TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' >> can raise this exception directly. You can have an empty list defined >> at the beginning instead of 'result list', append unresolvable >> conflicts to it and then at the end of the method check if it is >> non-empty and raise the exception. > Good suggestion, fixed. > >> >> 2.) >> >> + # In the code below: >> + # self -- the forest we establish trust to >> + # another_domain -- a forest that establishes trust to 'self' >> + # cinfo -- lsa_ForestTrustCollisionInfo structure that contain >> + # set of of lsa_ForestTrustCollisionRecord structures >> I would add this directly into the method docstring: >> >> """ >> ... >> >> :param self: the forest we establish trust to >> :param another_domain: a forest that establishes trust to 'self' >> :param cinfo: lsa_ForestTrustCollisionInfo structure that contain >> set of of lsa_ForestTrustCollisionRecord structures >> """ > Added. > >> Additionally, the behavior specifed in previous comment can be added >> using :raises: stanza: >> >> """ >> :raises: errors.TrustTopologyConflictError if there are unresolvable >> namespace conflicts between trusted domains >> """ > Added. > >> >> 3.) >> >> rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to >> simplify code in 'update_ftinfo' like this: >> >> """ >> - res = self.clear_ftinfo_conflict(another_domain, cinfo) >> - if len(res[1]) != 0: >> - domains = [x.name.string for x in res[1]] >> - raise errors.TrustTopologyConflictError( >> - target=self.info['dns_domain'], >> - >> conflict=another_domain.info['dns_domain'], >> - domains=domains) >> - else: >> - raise errors.TrustTopologyConflictSolved( >> - target=self.info['dns_domain'], >> - >> conflict=another_domain.info['dns_domain']) >> + self.clear_ftinfo_conflict(another_domain, cinfo) >> + raise errors.TrustTopologyConflictSolved( >> + target=self.info['dns_domain'], >> + conflict=another_domain.info['dns_domain']) >> """ > done. > >> >> Patch 218: >> >> 1.) >> typo in the commit message: >> >> """ >> ... >> suffixes are forest-wide, there *are could be* user accounts in the >> ... >> """ > Fixed. > > Updated patches attached. PATCH 207: ACK, I am attaching rebased version for ipa-4-3. Please check if the rebase is correct. PATCH 218: I am attaching rebased version for control. Unfortunately, I am unable to properly test conflict resolution due to reasons beyond my control but it does not break any ordinary workflows and code looks OK, so ACK. PATCH 219: ACK -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-3-abbra-0207-1-ipaserver-dcerpc-reformat-to-make-the-code-closer-to.patch Type: text/x-patch Size: 51662 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-3-abbra-0218-1-trust-automatically-resolve-DNS-trust-conflicts-for-.patch Type: text/x-patch Size: 17184 bytes Desc: not available URL: From gkaihoro at redhat.com Thu Aug 18 11:48:51 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Thu, 18 Aug 2016 07:48:51 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0004] [Test] Test for caacl-add-service: incorrect error message when service does not exists In-Reply-To: <1134476636.70352445.1471515501589.JavaMail.zimbra@redhat.com> Message-ID: <318616915.70407192.1471520931376.JavaMail.zimbra@redhat.com> Hello! Test for caacl-add-service: incorrect error message when service does not exists https://fedorahosted.org/freeipa/ticket/6171 Best regards, Ganna Kaihorodova Associate Software Quality Engineer : -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-gkaihoro-0004-Test-for-caacl-add-service.patch Type: text/x-patch Size: 1461 bytes Desc: not available URL: From tkrizek at redhat.com Thu Aug 18 12:02:12 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Thu, 18 Aug 2016 14:02:12 +0200 Subject: [Freeipa-devel] [PATCH 0562] Fix: container owner should be able to add vault In-Reply-To: References: Message-ID: I forgot about the oneliner rule, but for what it's worth - ACK. On 08/18/2016 01:04 PM, Martin Basti wrote: > > > > On 18.08.2016 12:04, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/6159 >> >> >> Patch attached. >> >> >> > Pushed to master: 6b7d6417d403c983691c790c1e60cfe32bf1c420 > > Pushed under oneliner rule > > -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkrizek at redhat.com Thu Aug 18 13:02:03 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Thu, 18 Aug 2016 15:02:03 +0200 Subject: [Freeipa-devel] [PATCH 0004] [Test] Test for caacl-add-service: incorrect error message when service does not exists In-Reply-To: <318616915.70407192.1471520931376.JavaMail.zimbra@redhat.com> References: <318616915.70407192.1471520931376.JavaMail.zimbra@redhat.com> Message-ID: <11c6200c-1235-540d-f165-5b9f73340902@redhat.com> Hi, NACK. The issue is not that the error message contains the "no such entry" string. That is actually a valid part of the error message if the service indeed does not exist. The problem is that the error message contained only the first character of the service's name instead of the entire name of the service. For example, the command ipa caacl-add-service test_caacl --services svc/master2.ipa.test --services svc/master1.ipa.test should end with these error messages if those services do not exist: member service: svc/master2.ipa.test at IPA.TEST: no such entry member service: svc/master1.ipa.test at IPA.TEST: no such entry There is also a typo in the file name of the test and I'm also not sure if there isn't a better place to put the test. On 08/18/2016 01:48 PM, Ganna Kaihorodova wrote: > Hello! > > Test for caacl-add-service: incorrect error message when service does not exists > https://fedorahosted.org/freeipa/ticket/6171 > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > : > > -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Aug 18 13:34:43 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 18 Aug 2016 15:34:43 +0200 Subject: [Freeipa-devel] [PATCH 0004] [Test] Test for caacl-add-service: incorrect error message when service does not exists In-Reply-To: <11c6200c-1235-540d-f165-5b9f73340902@redhat.com> References: <318616915.70407192.1471520931376.JavaMail.zimbra@redhat.com> <11c6200c-1235-540d-f165-5b9f73340902@redhat.com> Message-ID: <715f76fb-9341-fdaf-8507-afb6b5d898ee@redhat.com> On 18.08.2016 15:02, Tomas Krizek wrote: > > Hi, > > NACK. > > The issue is not that the error message contains the "no such entry" > string. That is actually a valid part of the error message if the > service indeed does not exist. > > The problem is that the error message contained only the first > character of the service's name instead of the entire name of the > service. For example, the command > > ipa caacl-add-service test_caacl --services svc/master2.ipa.test --services svc/master1.ipa.test > > should end with these error messages if those services do not exist: > > member service:svc/master2.ipa.test at IPA.TEST: no such entry > member service:svc/master1.ipa.test at IPA.TEST: no such entry > > There is also a typo in the file name of the test and I'm also not sure if there isn't a better place to put the test. +1 This should not be integration_test but only test_xmlrpc Martin^2 > > On 08/18/2016 01:48 PM, Ganna Kaihorodova wrote: >> Hello! >> >> Test for caacl-add-service: incorrect error message when service does not exists >> https://fedorahosted.org/freeipa/ticket/6171 >> >> Best regards, >> Ganna Kaihorodova >> Associate Software Quality Engineer >> >> >> : >> >> > > -- > Tomas Krizek > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Aug 18 14:25:10 2016 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Aug 2016 16:25:10 +0200 Subject: [Freeipa-devel] FreeIPA wiki - fighting the spammers Message-ID: <05e9c591-0632-83c1-abb2-bb7b526621c8@redhat.com> Hello everyone, As some of you noticed, we had lately an increasing number of spam attacks against FreeIPA.org wiki. Even though we did not accept user registration through the standard Mediawiki User Creation form (which is often misused by attacked) and only allow Fedora users logged in by OpenID, the spam producers started to favor this authentication mode too. This week and especially yesterday, the spam activity was high enough to warrant a "drastic change" in how we allow wiki modifications. Me and Petr Vobornik had to react quickly yesterday to hundreds of new spam-based pages (thanks to Petr for deleting the spam pages, Stephen for altering us and Patrick Uiterwijk for advising us!). As a prevention for future attacks, I also needed to chose the most simple and convenient method to stop spammers from editing wiki. This is the result: - Anonymous and regular users are no longer allowed to create or edit wiki pages - Anyone who wants to be able to edit wiki needs to be in a new "editor" group The full description of new group rights is here: http://www.freeipa.org/page/Special:ListGroupRights I added the contributors active in the last 30 days to the editor group. If more people are needed, wiki "Bureaucrats" can it through this form: http://www.freeipa.org/page/Special:UserRights If you do not know who is in the Bureaucrat group, this is the list: http://www.freeipa.org/index.php?title=Special%3AListUsers&username=&group=bureaucrat&limit=50 The model I had in mind was that new wiki contributors would ask for access on #freeipa IRC channel, when they have some content to be added to the pages. We should probably add that suggestion to the wiki somewhere. I hope this works for you. If you have comments on above or even better ideas what is the easiest way to fight spam on our precious wiki, please let me know. -- Martin Kosek Manager, Software Engineering - Identity Management Team Red Hat, Inc. From mbabinsk at redhat.com Thu Aug 18 15:13:43 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 18 Aug 2016 17:13:43 +0200 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> <20160817112037.phvkgo3zbw55gujk@redhat.com> Message-ID: <14dd21f5-560f-c78a-f333-24af67f7f8ea@redhat.com> On 08/18/2016 01:25 PM, Martin Babinsky wrote: > On 08/17/2016 01:20 PM, Alexander Bokovoy wrote: >> On Wed, 17 Aug 2016, Martin Babinsky wrote: >>> Hi Alexander, >>> >>> patch 207: LGTM, but I have a feeling that the patch should be linked >>> to both #6021 and #6076 so that it is not lost during backports. >>> >>> patch 218: >>> >>> ipalib/errors.py: >>> >>> 1.) >>> I'm not sure if TrustTopologyConflictError should inherit from >>> InvocationError. The semantics of InvocationError implies that >>> something was wrong when trying to invoke the command (a param failed >>> to validate/convert, incorrect number of args, etc.), while this is >>> more of an exception during command execution (no. and type of params >>> was correct, command started to execute but encountered an error >>> condition). Thus I think it should inherit from ExecutionError. CC'ing >>> Jan for more thoughts on this. >> Using ExecutionError would work to me too, as long as we display the >> error to a user. >>> Why is TrustTopologyConflictSolved listed amogn public errors? Since >>> it is used only in dcerpc.py to restart trust establishment after >>> resolving conflicts, it should be a private exception in dcerpc.py for >>> this purpose. >> I originally wanted to make it a warning -- i.e. if we fixed the >> conflict, return the result and show the warning that we did solve the >> conflict. After all, the code is modifying another trusted forest's >> topology on behalf of the user. I can move the error class to dcerpc.py >> >> >>> 3.) >>> Also please split the exception format string like this so that the >>> line is not too long (there is not much we can do about doctest so >>> leave that line as it is): >>> >>> @@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): >>> """ >>> >>> errno = 3017 >>> - format = _("Forest '%(forest)s' has existing trust to forest(s) >>> %(domains)s which prevents a trust to '%(conflict)s'") >>> + format = _("Forest '%(forest)s' has existing trust to forest(s) " >>> + "%(domains)s which prevents a trust to '%(conflict)s'") >>> >>> Do not worry about gettext, it can handle it just fine, there are >>> plenty of examples in server plugins, for example. >> Done. >> >>> ipaserver/dcerpc.py: >>> >>> 1.) >>> >>> I think that instead of returning result and raising >>> TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' >>> can raise this exception directly. You can have an empty list defined >>> at the beginning instead of 'result list', append unresolvable >>> conflicts to it and then at the end of the method check if it is >>> non-empty and raise the exception. >> Good suggestion, fixed. >> >>> >>> 2.) >>> >>> + # In the code below: >>> + # self -- the forest we establish trust to >>> + # another_domain -- a forest that establishes trust to 'self' >>> + # cinfo -- lsa_ForestTrustCollisionInfo structure that contain >>> + # set of of lsa_ForestTrustCollisionRecord structures >>> I would add this directly into the method docstring: >>> >>> """ >>> ... >>> >>> :param self: the forest we establish trust to >>> :param another_domain: a forest that establishes trust to 'self' >>> :param cinfo: lsa_ForestTrustCollisionInfo structure that contain >>> set of of lsa_ForestTrustCollisionRecord structures >>> """ >> Added. >> >>> Additionally, the behavior specifed in previous comment can be added >>> using :raises: stanza: >>> >>> """ >>> :raises: errors.TrustTopologyConflictError if there are unresolvable >>> namespace conflicts between trusted domains >>> """ >> Added. >> >>> >>> 3.) >>> >>> rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to >>> simplify code in 'update_ftinfo' like this: >>> >>> """ >>> - res = self.clear_ftinfo_conflict(another_domain, cinfo) >>> - if len(res[1]) != 0: >>> - domains = [x.name.string for x in res[1]] >>> - raise errors.TrustTopologyConflictError( >>> - target=self.info['dns_domain'], >>> - >>> conflict=another_domain.info['dns_domain'], >>> - domains=domains) >>> - else: >>> - raise errors.TrustTopologyConflictSolved( >>> - target=self.info['dns_domain'], >>> - >>> conflict=another_domain.info['dns_domain']) >>> + self.clear_ftinfo_conflict(another_domain, cinfo) >>> + raise errors.TrustTopologyConflictSolved( >>> + target=self.info['dns_domain'], >>> + conflict=another_domain.info['dns_domain']) >>> """ >> done. >> >>> >>> Patch 218: >>> >>> 1.) >>> typo in the commit message: >>> >>> """ >>> ... >>> suffixes are forest-wide, there *are could be* user accounts in the >>> ... >>> """ >> Fixed. >> >> Updated patches attached. > > PATCH 207: ACK, I am attaching rebased version for ipa-4-3. Please check > if the rebase is correct. > > PATCH 218: I am attaching rebased version for control. Unfortunately, I > am unable to properly test conflict resolution due to reasons beyond my > control but it does not break any ordinary workflows and code looks OK, > so ACK. > I have noticed that raising of TrustTopologyConflictSolved is broken. I have changed the base class to Exception and it works. Attaching patches with the change. > PATCH 219: ACK > > > -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-3-abbra-218-2-trust-automatically-resolve-DNS-trust-conflicts-for-.patch Type: text/x-patch Size: 17172 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-abbra-218-2-trust-automatically-resolve-DNS-trust-conflicts-for-.patch Type: text/x-patch Size: 17393 bytes Desc: not available URL: From pspacek at redhat.com Fri Aug 19 06:43:25 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 19 Aug 2016 08:43:25 +0200 Subject: [Freeipa-devel] FreeIPA wiki - fighting the spammers In-Reply-To: <05e9c591-0632-83c1-abb2-bb7b526621c8@redhat.com> References: <05e9c591-0632-83c1-abb2-bb7b526621c8@redhat.com> Message-ID: On 18.8.2016 16:25, Martin Kosek wrote: > Hello everyone, > > As some of you noticed, we had lately an increasing number of spam attacks > against FreeIPA.org wiki. Even though we did not accept user registration > through the standard Mediawiki User Creation form (which is often misused by > attacked) and only allow Fedora users logged in by OpenID, the spam producers > started to favor this authentication mode too. > > This week and especially yesterday, the spam activity was high enough to > warrant a "drastic change" in how we allow wiki modifications. Me and Petr > Vobornik had to react quickly yesterday to hundreds of new spam-based pages > (thanks to Petr for deleting the spam pages, Stephen for altering us and > Patrick Uiterwijk for advising us!). > > As a prevention for future attacks, I also needed to chose the most simple and > convenient method to stop spammers from editing wiki. This is the result: > > - Anonymous and regular users are no longer allowed to create or edit wiki pages > - Anyone who wants to be able to edit wiki needs to be in a new "editor" group > > The full description of new group rights is here: > http://www.freeipa.org/page/Special:ListGroupRights > > I added the contributors active in the last 30 days to the editor group. If > more people are needed, wiki "Bureaucrats" can it through this form: > http://www.freeipa.org/page/Special:UserRights > > If you do not know who is in the Bureaucrat group, this is the list: > http://www.freeipa.org/index.php?title=Special%3AListUsers&username=&group=bureaucrat&limit=50 > > The model I had in mind was that new wiki contributors would ask for access on > #freeipa IRC channel, when they have some content to be added to the pages. We > should probably add that suggestion to the wiki somewhere. > > I hope this works for you. If you have comments on above or even better ideas > what is the easiest way to fight spam on our precious wiki, please let me know. In general I agree. My attempt to edit "permission denied" error using http://www.freeipa.org/page/Special:AllMessages failed so I do not know. For the beginning, I added note about this new process to http://www.freeipa.org/page/Contribute#Contribute_documentation and link to the process page to http://www.freeipa.org/page/HowTo/Writing_how_to_documentation_on_the_wiki Now the question is how to make information about getting edit access *really visible*. Is this enough? I'm not sure. -- Petr^2 Spacek From mkosek at redhat.com Fri Aug 19 07:13:33 2016 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Aug 2016 09:13:33 +0200 Subject: [Freeipa-devel] FreeIPA wiki - fighting the spammers In-Reply-To: References: <05e9c591-0632-83c1-abb2-bb7b526621c8@redhat.com> Message-ID: <6b84a36b-5c7b-b3c9-2302-e5a9ba5f98ae@redhat.com> On 08/19/2016 08:43 AM, Petr Spacek wrote: > On 18.8.2016 16:25, Martin Kosek wrote: >> Hello everyone, >> >> As some of you noticed, we had lately an increasing number of spam attacks >> against FreeIPA.org wiki. Even though we did not accept user registration >> through the standard Mediawiki User Creation form (which is often misused by >> attacked) and only allow Fedora users logged in by OpenID, the spam producers >> started to favor this authentication mode too. >> >> This week and especially yesterday, the spam activity was high enough to >> warrant a "drastic change" in how we allow wiki modifications. Me and Petr >> Vobornik had to react quickly yesterday to hundreds of new spam-based pages >> (thanks to Petr for deleting the spam pages, Stephen for altering us and >> Patrick Uiterwijk for advising us!). >> >> As a prevention for future attacks, I also needed to chose the most simple and >> convenient method to stop spammers from editing wiki. This is the result: >> >> - Anonymous and regular users are no longer allowed to create or edit wiki pages >> - Anyone who wants to be able to edit wiki needs to be in a new "editor" group >> >> The full description of new group rights is here: >> http://www.freeipa.org/page/Special:ListGroupRights >> >> I added the contributors active in the last 30 days to the editor group. If >> more people are needed, wiki "Bureaucrats" can it through this form: >> http://www.freeipa.org/page/Special:UserRights >> >> If you do not know who is in the Bureaucrat group, this is the list: >> http://www.freeipa.org/index.php?title=Special%3AListUsers&username=&group=bureaucrat&limit=50 >> >> The model I had in mind was that new wiki contributors would ask for access on >> #freeipa IRC channel, when they have some content to be added to the pages. We >> should probably add that suggestion to the wiki somewhere. >> >> I hope this works for you. If you have comments on above or even better ideas >> what is the easiest way to fight spam on our precious wiki, please let me know. > > In general I agree. > > My attempt to edit "permission denied" error using > http://www.freeipa.org/page/Special:AllMessages > failed so I do not know. > > For the beginning, I added note about this new process to > http://www.freeipa.org/page/Contribute#Contribute_documentation > and link to the process page to > http://www.freeipa.org/page/HowTo/Writing_how_to_documentation_on_the_wiki > > > Now the question is how to make information about getting edit access *really > visible*. Is this enough? I'm not sure. Thanks Petr! I just made the warning into admonition box and fixed the wording a bit. It seems pretty visible now. Martin From freeipa-github-notification at redhat.com Fri Aug 19 08:08:25 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Fri, 19 Aug 2016 10:08:25 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #2] Remove forgotten print from DN.__str__ implementation (opened) In-Reply-To: References: Message-ID: mbasti-rh's pull request #2: "Remove forgotten print from DN.__str__ implementation" was opened PR body: These debug prints were forgotten there and should be removed, because str(DN) is often operation and we may save time with handling exceptions and printing unwanted debug See the full pull-request at https://github.com/freeipa/freeipa/pull/2 From abokovoy at redhat.com Fri Aug 19 08:28:02 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Aug 2016 11:28:02 +0300 Subject: [Freeipa-devel] [PATCH 0215-0216] Child domain fixes for AD trust In-Reply-To: <36addf67-0223-b8a5-9aa5-9519f9e2c0ec@redhat.com> References: <20160808112722.ldzcfmfpdzzmumex@redhat.com> <36addf67-0223-b8a5-9aa5-9519f9e2c0ec@redhat.com> Message-ID: <20160819082802.cfsxjpfs4vssa7yx@redhat.com> On Wed, 17 Aug 2016, Martin Babinsky wrote: >On 08/08/2016 01:27 PM, Alexander Bokovoy wrote: >>Hi! >> >>Attached two patches attempt to fix some of the issues we see with child >>domains. >> >>SSSD only 'sees' users from child domains if there is an ID range for >>each of them. However, after refactoring of trust code when external >>trust was introduced, part of the range creation had wrong assumption >>that if a trusted domain exists, its range also exists. This is now >>fixed to try to create range even if the domain exists. In fact, because >>the older code was not going to the range creation for trusted domains >>which already existed, adding ranges was done incorrectly: ID ranges use >>full domain name and don't need - hierarchy, but the code >>was passing both parent and the child names. As result, an attempt to >>create an ID range for parent was done instead of the child. Parent ID >>range already existed so we never got to create child ID ranges at all >>in that case. >> >>Finally, there is a fix in SSSD to properly generate CA paths so that >>libkrb5 can calculate correct trust path via forest root (parent) >>domain. While looking at that, I also decided to simplify logic in >>ipa-kdb driver because for cross-forest trust we never can transit to >>the child domain directly, we always have to use the forest root domain. >>However, old code could actually set a immediate domain's parent instead >>of the forest root for deep level trust relationship within the forest >>we trust. As we still cannot get to second level or beyond directly or >>via their actual parent domain, we always have to go through the forest >>root domain. The simplified code enforces this logic. >> >> >> >> > >ACK, but patch 215 needs rebase for ipa-4-3 and ipa-4-2. > Rebased version attached. -- / Alexander Bokovoy -------------- next part -------------- From 62f3af93ca780921355d8ed17ab6d9c42e452cb3 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Sat, 6 Aug 2016 11:12:13 +0300 Subject: [PATCH 1/3] trust: make sure ID range is created for the child domain even if it exists ID ranges for child domains of a forest trust were created incorrectly in FreeIPA 4.4.0 due to refactoring of -- if the domain was already existing, we never attempted to create the ID range for it. At the same time, when domain was missing, we attempted to add ID range and passed both forest root and the child domain names to add_range(). However, add_range() only looks at the first positional argument which was the forest root name. That ID range always exists (it is created before child domains are processed). Modify the code to make sure child domain name is passed as the first positional argument. In addition, the oddjob helper should explicitly set context='server' so that idrange code will be able to see and use ipaserver/dcerpc.py helpers. Resolves: https://fedorahosted.org/freeipa/ticket/5738 --- install/oddjob/com.redhat.idm.trust-fetch-domains | 2 +- ipalib/plugins/trust.py | 13 +++++++++---- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/install/oddjob/com.redhat.idm.trust-fetch-domains b/install/oddjob/com.redhat.idm.trust-fetch-domains index 4c50c43..f5ec8d7 100755 --- a/install/oddjob/com.redhat.idm.trust-fetch-domains +++ b/install/oddjob/com.redhat.idm.trust-fetch-domains @@ -75,7 +75,7 @@ env._bootstrap(context='server', debug=options.debug, log=None) env._finalize_core(**dict(DEFAULT_CONFIG)) # Initialize the API with the proper debug level -api.bootstrap(context='server', debug=env.debug, log=None) +api.bootstrap(in_server=True, debug=env.debug, log=None, context='server') api.finalize() # Only import trust plugin after api is initialized or internal imports diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 8672669..c2e5745 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -1592,14 +1592,19 @@ def add_new_domains_from_trust(myapi, trustinstance, trust_entry, domains, **opt if 'raw' in options: dom['raw'] = options['raw'] - res = myapi.Command.trustdomain_add(trust_name, name, **dom) - result.append(res['result']) + try: + res = myapi.Command.trustdomain_add(trust_name, name, **dom) + result.append(res['result']) + except errors.DuplicateEntry: + # Ignore updating duplicate entries + pass if idrange_type != u'ipa-ad-trust-posix': range_name = name.upper() + '_id_range' dom['range_type'] = u'ipa-ad-trust' - add_range(myapi, trustinstance, range_name, dom['ipanttrusteddomainsid'], - trust_name, name, **dom) + add_range(myapi, trustinstance, + range_name, dom['ipanttrusteddomainsid'], + name, **dom) except errors.DuplicateEntry: # Ignore updating duplicate entries pass -- 2.7.4 From freeipa-github-notification at redhat.com Fri Aug 19 09:39:11 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Fri, 19 Aug 2016 11:39:11 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #3] User add fix #6199 (opened) In-Reply-To: References: Message-ID: mbasti-rh's pull request #3: "User add fix #6199" was opened PR body: We do not have right to write to users delete_container. In case that user already exists in that container and we tried to add entry, we receive ACIError. This must be checked and DuplicationEntry error must be raised before. https://fedorahosted.org/freeipa/ticket/6199 See the full pull-request at https://github.com/freeipa/freeipa/pull/3 From abokovoy at redhat.com Fri Aug 19 09:43:45 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Aug 2016 12:43:45 +0300 Subject: [Freeipa-devel] [PATCH 0214] Support schema files for external plugins In-Reply-To: <20160808111248.3kpuzprcwxksfmgr@redhat.com> References: <20160808093459.ivfpnh5femnqf7mi@redhat.com> <20160808102626.ve3ubsyhjiotpzcp@redhat.com> <20160808111248.3kpuzprcwxksfmgr@redhat.com> Message-ID: <20160819094345.ioyyoujpps2gkpfj@redhat.com> On Mon, 08 Aug 2016, Alexander Bokovoy wrote: >On Mon, 08 Aug 2016, Petr Vobornik wrote: >>On 08/08/2016 12:26 PM, Alexander Bokovoy wrote: >>>On Mon, 08 Aug 2016, Alexander Bokovoy wrote: >>>>Hi! >>>> >>>>Attached patch is what is needed to allow external plugins for FreeIPA >>>>framework to be functional if they need to extend a schema. >>>> >>>>The idea is that we would have a separate directory as >>>>/usr/share/ipa/schema.d and will allow to use schema (*.ldif) files from >>>>it and its subdirectories during install and upgrade stages. >>>> >>>>Without the patch only selected schema files from /usr/share/ipa are >>>>used during install and upgrade. This leads to a failure to install IPA >>>>server (or upgrade it) if a new plugin is added. If plugin defines >>>>managed permissions, upgrade tool will generate ACIs which will fail to >>>>be inserted into LDAP store due to references to missing attributes and >>>>object classes. >>>> >>>>The patch adds a directory to be installed and a helper utility that >>>>loads files from the directory and adds them to the list of schema files >>>>used during update of dsinstance and upgrade of the server. >>>> >>>>With this patch I'm successfully managed to make FleetCommander >>>>integration plugin completely independent of FreeIPA. >>>Patch attached now. ;) >>> >> >>I'll assume that we want to target 4.4.x therefore it can be pushed to >>master, right? I.e. no need for creating ipa-4-4 branch atm. >Right. > >>Reasoning is that currently F24 has 4.3.x. F25 will most likely have >>4.4.x because 4.5 is still in planning. >Sounds good to me. FleetCommander (which is one of drivers behind the >patches) is targeting F25 as well. Can we get the patch reviewed? -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Fri Aug 19 09:56:07 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Fri, 19 Aug 2016 11:56:07 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #2] Remove forgotten print from DN.__str__ implementation (comment) In-Reply-To: References: Message-ID: davidkupka commented on a pull request Makes sence. See the full comment at https://github.com/freeipa/freeipa/pull/2#issuecomment-240977749 From ftweedal at redhat.com Fri Aug 19 10:09:33 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 19 Aug 2016 20:09:33 +1000 Subject: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name In-Reply-To: <20160815125425.GM23927@dhcp-40-8.bne.redhat.com> References: <20160715050448.GE10771@dhcp-40-8.bne.redhat.com> <20160715050539.GF10771@dhcp-40-8.bne.redhat.com> <83eb61a6-4e1f-d33a-1bbb-dacf8de522af@redhat.com> <20160719095445.GU10771@dhcp-40-8.bne.redhat.com> <4f7384ee-e648-2adb-3c86-26e297ede481@redhat.com> <63eec8fe-b64d-00db-f516-ccff6e8220a5@redhat.com> <20160815125425.GM23927@dhcp-40-8.bne.redhat.com> Message-ID: <20160819100933.GM3877@dhcp-40-8.bne.redhat.com> On Mon, Aug 15, 2016 at 10:54:25PM +1000, Fraser Tweedale wrote: > On Mon, Aug 15, 2016 at 02:08:54PM +0200, Jan Cholasta wrote: > > On 19.7.2016 12:05, Jan Cholasta wrote: > > > On 19.7.2016 11:54, Fraser Tweedale wrote: > > > > On Tue, Jul 19, 2016 at 09:36:17AM +0200, Jan Cholasta wrote: > > > > > Hi, > > > > > > > > > > On 15.7.2016 07:05, Fraser Tweedale wrote: > > > > > > On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: > > > > > > > The attached patch is a work in progress for > > > > > > > https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). > > > > > > > > > > > > > > I am sharing now to make the approach clear and solicit feedback. > > > > > > > > > > > > > > It has been tested for server install, replica install (with and > > > > > > > without CA) and CA-replica install (all hosts running master+patch). > > > > > > > > > > > > > > Migration from earlier versions and server/replica/CA install on a > > > > > > > CA-less deployment are not yet tested; these will be tested over > > > > > > > coming days and patch will be tweaked as necessary. > > > > > > > > > > > > > > Commit message has a fair bit to say so I won't repeat here but let > > > > > > > me know your questions and comments. > > > > > > > > > > > > > > Thanks, > > > > > > > Fraser > > > > > > > > > > > > > It does help to attach the patch, of course ^_^ > > > > > > > > > > IMO explicit is better than implicit, so instead of introducing > > > > > additional > > > > > magic around --subject, I would rather add a new separate option for > > > > > specifying the CA subject name (I think --ca-subject, for consistency > > > > > with > > > > > --ca-signing-algorithm). > > > > > > > > > The current situation - the --subject argument which specifies the > > > > not the subject but the subject base, is confusing enough (to say > > > > nothing of the limitations that give rise to the RFE). > > > > > > > > Retaining --subject for specifying the subject base and adding > > > > --ca-subject for specifying the *actual* subject DN gets us over the > > > > line in terms of the RFE, but does not make the installer less > > > > confusing. This is why I made --subject accept the full subject DN, > > > > with provisions to retain existing behaviour. > > > > > > > > IMO if we want to have separate arguments for subject DN and subject > > > > base (I am not against it), let's bite the bullet and name arguments > > > > accordingly. --subject should be used to specify full Subject DN, > > > > --subject-base (or similar) for specifying subject base. > > > > > > IMHO --ca-subject is better than --subject, because it is more explicit > > > whose subject name that is (the CA's). I agree that --subject should be > > > deprecated and replaced with --subject-base. > > > > > > > > > > > (I intentionally defer discussion of specific behaviour if one, none > > > > or both are specified; let's resolve the question or renaming / > > > > changing meaning of arguments first). > > > > > > > > > > > > > By specifying the option you would override the default "CN=Certificate > > > > > Authority,$SUBJECT_BASE" subject name. If --external-ca was not used, > > > > > additional validation would be done to make sure the subject name meets > > > > > Dogtag's expectations. Actually, it might make sense to always do the > > > > > additional validation, to be able to print a warning that if a > > > > > Dogtag-incompatible subject name is used, it won't be possible to > > > > > change the > > > > > CA cert chaining from externally signed to self-signed later. > > > > > > > > > > Honza > > > > Bump, any update on this? > > > I have an updated patch that fixes some issues Sebastian encountered > in testing, but I've not yet tackled the main change requested by > Honza (in brief: adding --ca-subject for specifying that, adding > --subject-base for specifying that, and deprecating --subject; > Sebastian, see discussion above and feel free to give your > thoughts). I expect I'll get back onto this work within the next > few days. > Update: I've got an updated version of patch almost ready for review, but I'm still ironing out some wrinkles in replica installation. Expect to be able to send it Monday or Tuesday for review. Thanks, Fraser From freeipa-github-notification at redhat.com Fri Aug 19 10:14:40 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Fri, 19 Aug 2016 12:14:40 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #2] Remove forgotten print from DN.__str__ implementation (comment) In-Reply-To: References: Message-ID: dkupka commented on a pull request Makes sence. See the full comment at https://github.com/freeipa/freeipa/pull/2#issuecomment-240981516 From freeipa-github-notification at redhat.com Fri Aug 19 10:30:00 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Fri, 19 Aug 2016 12:30:00 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #2] Remove forgotten print from DN.__str__ implementation (comment) In-Reply-To: References: Message-ID: dkupka commented on a pull request Makes sense. See the full comment at https://github.com/freeipa/freeipa/pull/2#issuecomment-240984276 From freeipa-github-notification at redhat.com Fri Aug 19 10:30:02 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Fri, 19 Aug 2016 12:30:02 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #2] Remove forgotten print from DN.__str__ implementation (label change) In-Reply-To: References: Message-ID: mbasti-rh's pull request #2: "Remove forgotten print from DN.__str__ implementation" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/2 From pvomacka at redhat.com Fri Aug 19 10:37:48 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 19 Aug 2016 12:37:48 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <14a86320-7801-f00e-98bf-14b46f6a4d81@redhat.com> References: <14a86320-7801-f00e-98bf-14b46f6a4d81@redhat.com> Message-ID: On 08/16/2016 08:21 AM, Stanislav Laznicka wrote: > On 08/12/2016 06:48 PM, Petr Spacek wrote: >> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>> Hello, >>> >>> I updated the design of the Time-Based HBAC Policies according to the >>> discussion we led here earlier. Please check the design page >>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest >>> changes are in the Implementation and Feature Management sections. I >>> also >>> added a short How to Use section. > Thank you for the review! I will add some comments inline. >> Nice page! >> >> On the high level it all makes sense. >> >> ad LDAP schema >> ============== >> 1) Why accessTime attribute is MAY in ipaTimeRule object class? >> Does it make sense to have the object without accessTime? I do not >> think so. > My idea was that we allow users prepare a few time rule objects before > filling them with the actual times. >> Also, it could be good to add description attribute to the object >> class and >> incorporate it into commands (including find). >> > Definitely a good idea, I will work that in. >> 2) Besides all this, I spent few minutes in dark history of IPA. The >> accessTime attribute was introduced back in 2009 in commit >> "55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new >> schema for IPAv2". >> >> The commit does not contain any reasoning for the change but I can >> see that >> the attribute is already used as MAY in old object classes >> ipaHBACRule and >> ipaSELinuxUserMap. >> >> Is any of these a problem? > I believe that the accessTime attribute was originally brought to IPA > when there was an implementation of time policies for HBAC objects and > it's been rotting there ever since those capabilities were removed. We > may eventually use a new attribute for storage of the time strings as > accessTime by definition is multi-valued which is not what's currently > desired (although we may end up with it some day in the future). > However, I don't think any other use of accessTime should be a problem > as it's been obsoleted for a long time. >> Why is it even in ipaSELinuxUserMap object class? > I'm sorry to say I have no idea. I used it for what it originally was > - a means for storing time strings at HBAC rules. >> Commit >> 55512dc938eb4a9a6655e473beab587e340af55c does not mention any reason >> for doing so. >> >> I cannot see any other problem so the low-level stuff is good and can be >> implemented. >> >> >> ad User interface >> ================= >> We need to polish the user interface so it really usable. >> >> At least the web interface should contain some shortcuts. E.g. when >> I'm adding >> a new HBAC rule, the "time" section should contain also "something" to >> immediately add new time rule so I do not need to go to time rules >> first and >> then go back to HBAC page. I'm definitely for creating a field where admin can choose a existing time rule when creating a new HBAC. But I'm not sure about possibility to create and define new time rule in dialog for creating new HBAC. I think that mixing these two things together is like a possibility to create a new user when you are creating a user group. Which is mixing two different things together. I can imagine a button like "Create HBAC and add a new time rule to it" which could store new HBAC rule and immediately take admin to the page (or dialog) where admin can create a new time rule with prefilled HBAC rule. But as you write below it would be good to discuss it with some UX designer. >> >> Similarly, dialog for rule modification should allow to easily change >> all the >> values, warn if time rules is shared, and also have an easy way to >> 'disconnect' the time rule, i.e. make a copy of it and edit only the >> new copy >> (instead of the shared original). >> All of these points are really good. >> All these are user interface things not affecting the low-level stuff. >> >> >> Maybe you should sat down with some UX designer, talk about these >> cases and >> draw some hand-made pictures. > I will add Pavel V. to CC, we may want to discuss this. >> I do not believe that this will require any changes in schema so you can >> polish SSSD and framework implementation in meantime. >> >> On the link below is a PROTOTYPE-patched FreeIPA that covers most of >> the CLI >> functionality (except for the creation of iCalendar strings from >> options) for >> better illustration of the design. >> >> https://github.com/stlaz/freeipa/tree/timerules_2 >> Honestly I did not look at the code today :-) >> >> Overall, I'm glad to see current proposal. After so many iteration, >> we reached >> something which does not have any glaring problem :-) > It definitely felt better to be writing it with all the previous > knowledge. Thank you! :-) -- Pavel^3 Vomacka From ftweedal at redhat.com Fri Aug 19 10:55:10 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 19 Aug 2016 20:55:10 +1000 Subject: [Freeipa-devel] [PATCH] 0084 cert-revoke: fix permission check bypass Message-ID: <20160819105510.GN3877@dhcp-40-8.bne.redhat.com> This patch fixes CVE-2016-5404. Versions for master, ipa-4-3 and ipa-4-2 branches are attached. Thanks, Fraser -------------- next part -------------- From 61590c223aa51668b3f661fc91bc35f2dfae8ae6 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Jun 2016 10:21:01 +1000 Subject: [PATCH] cert-revoke: fix permission check bypass (CVE-2016-5404) The 'cert_revoke' command checks the 'revoke certificate' permission, however, if an ACIError is raised, it then invokes the 'cert_show' command. The rational was to re-use a "host manages certificate" check that is part of the 'cert_show' command, however, it is sufficient that 'cert_show' executes successfully for 'cert_revoke' to recover from the ACIError continue. Therefore, anyone with 'retrieve certificate' permission can revoke *any* certificate and cause various kinds of DoS. Fix the problem by extracting the "host manages certificate" check to its own method and explicitly calling it from 'cert_revoke'. Fixes: https://fedorahosted.org/freeipa/ticket/6232 --- ipaserver/plugins/cert.py | 60 +++++++++++++++++++++++++---------------------- 1 file changed, 32 insertions(+), 28 deletions(-) diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index b8df074a186ca91daa8e8f5e725724ea7bc5a663..6dd9f6ffcdcd9d051d50d912996fea2104d71dff 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -242,6 +242,24 @@ def validate_certificate(value): return x509.validate_certificate(value, x509.DER) +def bind_principal_can_manage_cert(cert): + """Check that the bind principal can manage the given cert. + + ``cert`` + An NSS certificate object. + + """ + bind_principal = kerberos.Principal(getattr(context, 'principal')) + if not bind_principal.is_host: + return False + + hostname = bind_principal.hostname + + # If we have a hostname we want to verify that the subject + # of the certificate matches it. + return hostname == cert.subject.common_name #pylint: disable=E1101 + + class BaseCertObject(Object): takes_params = ( Bytes( @@ -744,18 +762,6 @@ class cert_show(Retrieve, CertMethod, VirtualCommand): def execute(self, serial_number, all=False, raw=False, no_members=False, **options): ca_enabled_check() - hostname = None - try: - self.check_access() - except errors.ACIError as acierr: - self.debug("Not granted by ACI to retrieve certificate, looking at principal") - bind_principal = kerberos.Principal(getattr(context, 'principal')) - if not bind_principal.is_host: - raise acierr - hostname = bind_principal.hostname - - ca_obj = api.Command.ca_show(options['cacn'])['result'] - issuer_dn = ca_obj['ipacasubjectdn'][0] # Dogtag lightweight CAs have shared serial number domain, so # we don't tell Dogtag the issuer (but we check the cert after). @@ -763,7 +769,15 @@ class cert_show(Retrieve, CertMethod, VirtualCommand): result = self.Backend.ra.get_certificate(str(serial_number)) cert = x509.load_certificate(result['certificate']) - if DN(unicode(cert.issuer)) != DN(issuer_dn): + try: + self.check_access() + except errors.ACIError as acierr: + self.debug("Not granted by ACI to retrieve certificate, looking at principal") + if not bind_principal_can_manage_cert(cert): + raise acierr # pylint: disable=E0702 + + ca_obj = api.Command.ca_show(options['cacn'])['result'] + if DN(unicode(cert.issuer)) != DN(ca_obj['ipacasubjectdn'][0]): # DN of cert differs from what we requested raise errors.NotFound( reason=_("Certificate with serial number %(serial)s " @@ -789,12 +803,6 @@ class cert_show(Retrieve, CertMethod, VirtualCommand): result['revoked'] = ('revocation_reason' in result) self.obj._fill_owners(result) - if hostname: - # If we have a hostname we want to verify that the subject - # of the certificate matches it, otherwise raise an error - if hostname != cert.subject.common_name: #pylint: disable=E1101 - raise acierr - return dict(result=result, value=pkey_to_value(serial_number, options)) @@ -819,22 +827,18 @@ class cert_revoke(PKQuery, CertMethod, VirtualCommand): # Make sure that the cert specified by issuer+serial exists. # Will raise NotFound if it does not. - cert_show_options = dict(cacn=kw['cacn']) - api.Command.cert_show(unicode(serial_number), **cert_show_options) + resp = api.Command.cert_show(unicode(serial_number), cacn=kw['cacn']) - hostname = None try: self.check_access() except errors.ACIError as acierr: self.debug("Not granted by ACI to revoke certificate, looking at principal") try: - # Let cert_show() handle verifying that the subject of the - # cert we're dealing with matches the hostname in the principal - result = api.Command['cert_show']( - unicode(serial_number), **cert_show_options - )['result'] + cert = x509.load_certificate(resp['result']['certificate']) + if not bind_principal_can_manage_cert(cert): + raise acierr except errors.NotImplementedError: - pass + raise acierr revocation_reason = kw['revocation_reason'] if revocation_reason == 7: raise errors.CertificateOperationError(error=_('7 is not a valid revocation reason')) -- 2.5.5 -------------- next part -------------- From d68f99203c5bab33e8bc4af6becea57e0736bbc5 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Jun 2016 10:21:01 +1000 Subject: [PATCH] cert-revoke: fix permission check bypass (CVE-2016-5404) The 'cert_revoke' command checks the 'revoke certificate' permission, however, if an ACIError is raised, it then invokes the 'cert_show' command. The rational was to re-use a "host manages certificate" check that is part of the 'cert_show' command, however, it is sufficient that 'cert_show' executes successfully for 'cert_revoke' to recover from the ACIError continue. Therefore, anyone with 'retrieve certificate' permission can revoke *any* certificate and cause various kinds of DoS. Fix the problem by extracting the "host manages certificate" check to its own method and explicitly calling it from 'cert_revoke'. Fixes: https://fedorahosted.org/freeipa/ticket/6232 --- ipalib/plugins/cert.py | 49 +++++++++++++++++++++++++++++++------------------ 1 file changed, 31 insertions(+), 18 deletions(-) diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index b4ea2feae5de9ffc020709092f79791d99472ffc..f257088e2d45a0c991cce68222577dbe212415d9 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -243,6 +243,25 @@ def caacl_check(principal_type, principal_string, ca, profile_id): ) ) + +def bind_principal_can_manage_cert(cert): + """Check that the bind principal can manage the given cert. + + ``cert`` + An NSS certificate object. + + """ + bind_principal = getattr(context, 'principal') + if not bind_principal.startswith('host/'): + return False + + hostname = get_host_from_principal(bind_principal) + + # If we have a hostname we want to verify that the subject + # of the certificate matches it. + return hostname == cert.subject.common_name #pylint: disable=E1101 + + @register() class cert_request(VirtualCommand): __doc__ = _('Submit a certificate signing request.') @@ -608,29 +627,23 @@ class cert_show(VirtualCommand): def execute(self, serial_number, **options): ca_enabled_check() - hostname = None - try: - self.check_access() - except errors.ACIError as acierr: - self.debug("Not granted by ACI to retrieve certificate, looking at principal") - bind_principal = getattr(context, 'principal') - if not bind_principal.startswith('host/'): - raise acierr - hostname = get_host_from_principal(bind_principal) result=self.Backend.ra.get_certificate(serial_number) cert = x509.load_certificate(result['certificate']) + + try: + self.check_access() + except errors.ACIError as acierr: + self.debug("Not granted by ACI to retrieve certificate, looking at principal") + if not bind_principal_can_manage_cert(cert): + raise acierr # pylint: disable=E0702 + result['subject'] = unicode(cert.subject) result['issuer'] = unicode(cert.issuer) result['valid_not_before'] = unicode(cert.valid_not_before_str) result['valid_not_after'] = unicode(cert.valid_not_after_str) result['md5_fingerprint'] = unicode(nss.data_to_hex(nss.md5_digest(cert.der_data), 64)[0]) result['sha1_fingerprint'] = unicode(nss.data_to_hex(nss.sha1_digest(cert.der_data), 64)[0]) - if hostname: - # If we have a hostname we want to verify that the subject - # of the certificate matches it, otherwise raise an error - if hostname != cert.subject.common_name: #pylint: disable=E1101 - raise acierr return dict(result=result) @@ -676,17 +689,17 @@ class cert_revoke(VirtualCommand): def execute(self, serial_number, **kw): ca_enabled_check() - hostname = None try: self.check_access() except errors.ACIError as acierr: self.debug("Not granted by ACI to revoke certificate, looking at principal") try: - # Let cert_show() handle verifying that the subject of the - # cert we're dealing with matches the hostname in the principal result = api.Command['cert_show'](unicode(serial_number))['result'] + cert = x509.load_certificate(result['certificate']) + if not bind_principal_can_manage_cert(cert): + raise acierr except errors.NotImplementedError: - pass + raise acierr revocation_reason = kw['revocation_reason'] if revocation_reason == 7: raise errors.CertificateOperationError(error=_('7 is not a valid revocation reason')) -- 2.5.5 -------------- next part -------------- From aa114a658b1f30e45f905bb6e19b04e9504da8a7 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Jun 2016 10:21:01 +1000 Subject: [PATCH] cert-revoke: fix permission check bypass (CVE-2016-5404) The 'cert_revoke' command checks the 'revoke certificate' permission, however, if an ACIError is raised, it then invokes the 'cert_show' command. The rational was to re-use a "host manages certificate" check that is part of the 'cert_show' command, however, it is sufficient that 'cert_show' executes successfully for 'cert_revoke' to recover from the ACIError continue. Therefore, anyone with 'retrieve certificate' permission can revoke *any* certificate and cause various kinds of DoS. Fix the problem by extracting the "host manages certificate" check to its own method and explicitly calling it from 'cert_revoke'. Fixes: https://fedorahosted.org/freeipa/ticket/6232 --- ipalib/plugins/cert.py | 49 +++++++++++++++++++++++++++++++------------------ 1 file changed, 31 insertions(+), 18 deletions(-) diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index 7a07039a8488cc11d9bf05ef23642b8059d5921e..42dc4f571b9274f45bd6c20910362cf676764f3a 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -236,6 +236,25 @@ def caacl_check(principal_type, principal_string, ca, profile_id): ) ) + +def bind_principal_can_manage_cert(cert): + """Check that the bind principal can manage the given cert. + + ``cert`` + An NSS certificate object. + + """ + bind_principal = getattr(context, 'principal') + if not bind_principal.startswith('host/'): + return False + + hostname = get_host_from_principal(bind_principal) + + # If we have a hostname we want to verify that the subject + # of the certificate matches it. + return hostname == cert.subject.common_name #pylint: disable=E1101 + + @register() class cert_request(VirtualCommand): __doc__ = _('Submit a certificate signing request.') @@ -601,29 +620,23 @@ class cert_show(VirtualCommand): def execute(self, serial_number, **options): ca_enabled_check() - hostname = None - try: - self.check_access() - except errors.ACIError, acierr: - self.debug("Not granted by ACI to retrieve certificate, looking at principal") - bind_principal = getattr(context, 'principal') - if not bind_principal.startswith('host/'): - raise acierr - hostname = get_host_from_principal(bind_principal) result=self.Backend.ra.get_certificate(serial_number) cert = x509.load_certificate(result['certificate']) + + try: + self.check_access() + except errors.ACIError as acierr: + self.debug("Not granted by ACI to retrieve certificate, looking at principal") + if not bind_principal_can_manage_cert(cert): + raise acierr # pylint: disable=E0702 + result['subject'] = unicode(cert.subject) result['issuer'] = unicode(cert.issuer) result['valid_not_before'] = unicode(cert.valid_not_before_str) result['valid_not_after'] = unicode(cert.valid_not_after_str) result['md5_fingerprint'] = unicode(nss.data_to_hex(nss.md5_digest(cert.der_data), 64)[0]) result['sha1_fingerprint'] = unicode(nss.data_to_hex(nss.sha1_digest(cert.der_data), 64)[0]) - if hostname: - # If we have a hostname we want to verify that the subject - # of the certificate matches it, otherwise raise an error - if hostname != cert.subject.common_name: #pylint: disable=E1101 - raise acierr return dict(result=result) @@ -669,17 +682,17 @@ class cert_revoke(VirtualCommand): def execute(self, serial_number, **kw): ca_enabled_check() - hostname = None try: self.check_access() except errors.ACIError, acierr: self.debug("Not granted by ACI to revoke certificate, looking at principal") try: - # Let cert_show() handle verifying that the subject of the - # cert we're dealing with matches the hostname in the principal result = api.Command['cert_show'](unicode(serial_number))['result'] + cert = x509.load_certificate(result['certificate']) + if not bind_principal_can_manage_cert(cert): + raise acierr except errors.NotImplementedError: - pass + raise acierr revocation_reason = kw['revocation_reason'] if revocation_reason == 7: raise errors.CertificateOperationError(error=_('7 is not a valid revocation reason')) -- 2.5.5 From freeipa-github-notification at redhat.com Fri Aug 19 11:05:26 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Fri, 19 Aug 2016 13:05:26 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #2] Remove forgotten print from DN.__str__ implementation (label change) In-Reply-To: References: Message-ID: mbasti-rh's pull request #2: "Remove forgotten print from DN.__str__ implementation" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/2 From freeipa-github-notification at redhat.com Fri Aug 19 11:05:28 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Fri, 19 Aug 2016 13:05:28 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #2] Remove forgotten print from DN.__str__ implementation (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request m a s t e r : * 8 6 e 1 5 6 c 3 c 5 f 3 3 1 e 3 f 1 6 9 b 9 4 1 b e 2 d 9 f 7 2 e 7 c 8 f 0 0 0 R e m o v e f o r g o t t e n p r i n t f r o m D N . _ _ s t r _ _ i m p l e m e n t a t i o n See the full comment at https://github.com/freeipa/freeipa/pull/2#issuecomment-240990609 From freeipa-github-notification at redhat.com Fri Aug 19 11:05:29 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Fri, 19 Aug 2016 13:05:29 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #2] Remove forgotten print from DN.__str__ implementation (closed) In-Reply-To: References: Message-ID: mbasti-rh's pull request #2: "Remove forgotten print from DN.__str__ implementation" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/2 From mbasti at redhat.com Fri Aug 19 11:07:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Aug 2016 13:07:44 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #2] Remove forgotten print from DN.__str__ implementation (comment) In-Reply-To: References: Message-ID: <95a8514e-9a30-fd3c-b2ad-60da987dbfbf@redhat.com> On 19.08.2016 13:05, freeipa-github-notification at redhat.com wrote: > mbasti-rh commented on a pull request > > m > a > s > t > e > r > : > > > * > > 8 > 6 > e > 1 > 5 > 6 > c > 3 > c > 5 > f > 3 > 3 > 1 > e > 3 > f > 1 > 6 > 9 > b > 9 > 4 > 1 > b > e > 2 > d > 9 > f > 7 > 2 > e > 7 > c > 8 > f > 0 > 0 > 0 > > R > e > m > o > v > e > > f > o > r > g > o > t > t > e > n > > p > r > i > n > t > > f > r > o > m > > D > N > . > _ > _ > s > t > r > _ > _ > > i > m > p > l > e > m > e > n > t > a > t > i > o > n > > See the full comment at https://github.com/freeipa/freeipa/pull/2#issuecomment-240990609 > > Sorry, this is testing phase of tools :) Pushed to master: 86e156c3c5f331e3f169b941be2d9f72e7c8f000 -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Fri Aug 19 11:08:04 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Fri, 19 Aug 2016 13:08:04 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #2] Remove forgotten print from DN.__str__ implementation (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request Sorry testing phase of tools :) Fixed upstream master: https://fedorahosted.org/freeipa/changeset/86e156c3c5f331e3f169b941be2d9f72e7c8f000 See the full comment at https://github.com/freeipa/freeipa/pull/2#issuecomment-240991058 From ftweedal at redhat.com Fri Aug 19 11:11:22 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 19 Aug 2016 21:11:22 +1000 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: <20160815071516.GL23927@dhcp-40-8.bne.redhat.com> References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> <20160815071516.GL23927@dhcp-40-8.bne.redhat.com> Message-ID: <20160819111122.GP3877@dhcp-40-8.bne.redhat.com> Bump for review. On Mon, Aug 15, 2016 at 05:15:16PM +1000, Fraser Tweedale wrote: > Thanks for reviews. Rebased and updated patches attached (and one > new patch). No substantive changes to 92..94. Patch order is: > > 92-2, 93-2, 94-2, 98, 90-3 > > Other comments inline. > > Thanks, > Fraser > > On Fri, Aug 12, 2016 at 11:33:28AM +0200, Jan Cholasta wrote: > > Patch 0092: ACK > > > > Patch 0093: ACK > > > > Patch 0094: ACK > > > > Patch 0090: > > > > 1) Generic otherNames (san_other) do not work correctly. The OID is not > > included in the value and names with complex type other than > > KerberosPrincipal are not parsed correctly. The value should include the OID > > and DER blob of the name. > > > Updated to use "OID:b64(DER)" as the attribute value. > > > 2) With --all, san_other should be included in the result for all > > otherNames, even the known ones, to provide (limited) forward compatibility. > > > Done; when --all given, known otherName kinds are included in > 'san_other' attribute in addition to their own attribute. > > > 3) Do we have to support *all* the name types? I mean we could, for the sake > > of completeness, but it might be easier to just keep the few ones we > > actually care about (email, DNS name, principal name, UPN and directory name > > in your patch 0095). > > > Yeah, why not support them all? See also Petr's comments in other > branch of thread. > > > 4) > > > > + obj.setdefault(attr_name, []).append(unicode(name)) > > > > The value should not (always) be unicode, but of the type declared by the > > param (unicode or ipapython.kerberos.Principal or > > ipapython.dnsutil.DNSName). > > > I now pass the value to the constructor of whatever type the > parameter uses: > > attr_value = self.params[attr_name].type(name_formatted) > obj.setdefault(attr_name, []).append(attr_value) > From 17e5515ab0eeb92d87091eb00a26dcf358060dba Mon Sep 17 00:00:00 2001 > From: Fraser Tweedale > Date: Thu, 21 Jul 2016 16:27:49 +1000 > Subject: [PATCH 92/94] Move GeneralName parsing code to ipalib.x509 > > GeneralName parsing code is primarily relevant to X.509. An > upcoming change will add SAN parsing to the cert-show command, so > first move the GeneralName parsing code from ipalib.pkcs10 to > ipalib.x509. > > Part of: https://fedorahosted.org/freeipa/ticket/6022 > --- > ipalib/pkcs10.py | 93 ++----------------------------------- > ipalib/x509.py | 114 +++++++++++++++++++++++++++++++++++++++++++++- > ipaserver/plugins/cert.py | 8 ++-- > 3 files changed, 120 insertions(+), 95 deletions(-) > > diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py > index e340c1a2005ad781542a32a0a76753e80364dacf..158ebb3a25be2bd292f3883545fe8afe49b7be8c 100644 > --- a/ipalib/pkcs10.py > +++ b/ipalib/pkcs10.py > @@ -22,9 +22,10 @@ from __future__ import print_function > import sys > import base64 > import nss.nss as nss > -from pyasn1.type import univ, char, namedtype, tag > +from pyasn1.type import univ, namedtype, tag > from pyasn1.codec.der import decoder > import six > +from ipalib import x509 > > if six.PY3: > unicode = str > @@ -32,11 +33,6 @@ if six.PY3: > PEM = 0 > DER = 1 > > -SAN_DNSNAME = 'DNS name' > -SAN_RFC822NAME = 'RFC822 Name' > -SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' > -SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' > - > def get_subject(csr, datatype=PEM): > """ > Given a CSR return the subject value. > @@ -72,78 +68,6 @@ def get_extensions(csr, datatype=PEM): > return tuple(get_prefixed_oid_str(ext)[4:] > for ext in request.extensions) > > -class _PrincipalName(univ.Sequence): > - componentType = namedtype.NamedTypes( > - namedtype.NamedType('name-type', univ.Integer().subtype( > - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) > - ), > - namedtype.NamedType('name-string', univ.SequenceOf(char.GeneralString()).subtype( > - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) > - ), > - ) > - > -class _KRB5PrincipalName(univ.Sequence): > - componentType = namedtype.NamedTypes( > - namedtype.NamedType('realm', char.GeneralString().subtype( > - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) > - ), > - namedtype.NamedType('principalName', _PrincipalName().subtype( > - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) > - ), > - ) > - > -def _decode_krb5principalname(data): > - principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0] > - realm = (str(principal['realm']).replace('\\', '\\\\') > - .replace('@', '\\@')) > - name = principal['principalName']['name-string'] > - name = '/'.join(str(n).replace('\\', '\\\\') > - .replace('/', '\\/') > - .replace('@', '\\@') for n in name) > - name = '%s@%s' % (name, realm) > - return name > - > -class _AnotherName(univ.Sequence): > - componentType = namedtype.NamedTypes( > - namedtype.NamedType('type-id', univ.ObjectIdentifier()), > - namedtype.NamedType('value', univ.Any().subtype( > - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) > - ), > - ) > - > -class _GeneralName(univ.Choice): > - componentType = namedtype.NamedTypes( > - namedtype.NamedType('otherName', _AnotherName().subtype( > - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) > - ), > - namedtype.NamedType('rfc822Name', char.IA5String().subtype( > - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) > - ), > - namedtype.NamedType('dNSName', char.IA5String().subtype( > - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2)) > - ), > - namedtype.NamedType('x400Address', univ.Sequence().subtype( > - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) > - ), > - namedtype.NamedType('directoryName', univ.Choice().subtype( > - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) > - ), > - namedtype.NamedType('ediPartyName', univ.Sequence().subtype( > - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 5)) > - ), > - namedtype.NamedType('uniformResourceIdentifier', char.IA5String().subtype( > - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 6)) > - ), > - namedtype.NamedType('iPAddress', univ.OctetString().subtype( > - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 7)) > - ), > - namedtype.NamedType('registeredID', univ.ObjectIdentifier().subtype( > - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 8)) > - ), > - ) > - > -class _SubjectAltName(univ.SequenceOf): > - componentType = _GeneralName() > > def get_subjectaltname(csr, datatype=PEM): > """ > @@ -159,19 +83,8 @@ def get_subjectaltname(csr, datatype=PEM): > return None > del request > > - nss_names = nss.x509_alt_name(extension.value, nss.AsObject) > - asn1_names = decoder.decode(extension.value.data, > - asn1Spec=_SubjectAltName())[0] > - names = [] > - for nss_name, asn1_name in zip(nss_names, asn1_names): > - name_type = nss_name.type_string > - if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: > - name = _decode_krb5principalname(asn1_name['otherName']['value']) > - else: > - name = nss_name.name > - names.append((name_type, name)) > + return x509.decode_generalnames(extension.value) > > - return tuple(names) > > # Unfortunately, NSS can only parse the extension request attribute, so > # we have to parse friendly name ourselves (see RFC 2986) > diff --git a/ipalib/x509.py b/ipalib/x509.py > index 82194922d151a1b0f2df03df3578ad45b43b71c9..15168de08240a84794efef409d022eaa983291c9 100644 > --- a/ipalib/x509.py > +++ b/ipalib/x509.py > @@ -40,7 +40,7 @@ import re > > import nss.nss as nss > from nss.error import NSPRError > -from pyasn1.type import univ, namedtype, tag > +from pyasn1.type import univ, char, namedtype, tag > from pyasn1.codec.der import decoder, encoder > import six > > @@ -63,6 +63,11 @@ EKU_EMAIL_PROTECTION = '1.3.6.1.5.5.7.3.4' > EKU_ANY = '2.5.29.37.0' > EKU_PLACEHOLDER = '1.3.6.1.4.1.3319.6.10.16' > > +SAN_DNSNAME = 'DNS name' > +SAN_RFC822NAME = 'RFC822 Name' > +SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' > +SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' > + > _subject_base = None > > def subject_base(): > @@ -374,6 +379,113 @@ def encode_ext_key_usage(ext_key_usage): > eku = encoder.encode(eku) > return _encode_extension('2.5.29.37', EKU_ANY not in ext_key_usage, eku) > > + > +class _AnotherName(univ.Sequence): > + componentType = namedtype.NamedTypes( > + namedtype.NamedType('type-id', univ.ObjectIdentifier()), > + namedtype.NamedType('value', univ.Any().subtype( > + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) > + ), > + ) > + > + > +class _GeneralName(univ.Choice): > + componentType = namedtype.NamedTypes( > + namedtype.NamedType('otherName', _AnotherName().subtype( > + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) > + ), > + namedtype.NamedType('rfc822Name', char.IA5String().subtype( > + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) > + ), > + namedtype.NamedType('dNSName', char.IA5String().subtype( > + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2)) > + ), > + namedtype.NamedType('x400Address', univ.Sequence().subtype( > + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) > + ), > + namedtype.NamedType('directoryName', univ.Choice().subtype( > + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) > + ), > + namedtype.NamedType('ediPartyName', univ.Sequence().subtype( > + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 5)) > + ), > + namedtype.NamedType('uniformResourceIdentifier', char.IA5String().subtype( > + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 6)) > + ), > + namedtype.NamedType('iPAddress', univ.OctetString().subtype( > + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 7)) > + ), > + namedtype.NamedType('registeredID', univ.ObjectIdentifier().subtype( > + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 8)) > + ), > + ) > + > + > +class _SubjectAltName(univ.SequenceOf): > + componentType = _GeneralName() > + > + > +class _PrincipalName(univ.Sequence): > + componentType = namedtype.NamedTypes( > + namedtype.NamedType('name-type', univ.Integer().subtype( > + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) > + ), > + namedtype.NamedType('name-string', univ.SequenceOf(char.GeneralString()).subtype( > + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) > + ), > + ) > + > + > +class _KRB5PrincipalName(univ.Sequence): > + componentType = namedtype.NamedTypes( > + namedtype.NamedType('realm', char.GeneralString().subtype( > + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) > + ), > + namedtype.NamedType('principalName', _PrincipalName().subtype( > + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) > + ), > + ) > + > + > +def _decode_krb5principalname(data): > + principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0] > + realm = (str(principal['realm']).replace('\\', '\\\\') > + .replace('@', '\\@')) > + name = principal['principalName']['name-string'] > + name = '/'.join(str(n).replace('\\', '\\\\') > + .replace('/', '\\/') > + .replace('@', '\\@') for n in name) > + name = '%s@%s' % (name, realm) > + return name > + > + > +def decode_generalnames(secitem): > + """ > + Decode a GeneralNames object (this the data for the Subject > + Alt Name and Issuer Alt Name extensions, among others). > + > + ``secitem`` > + The input is the DER-encoded extension data, without the > + OCTET STRING header, as an nss SecItem object. > + > + Return a list of tuples of name types (as string, suitable for > + presentation) and names (as string, suitable for presentation). > + > + """ > + nss_names = nss.x509_alt_name(secitem, repr_kind=nss.AsObject) > + asn1_names = decoder.decode(secitem.data, asn1Spec=_SubjectAltName())[0] > + names = [] > + for nss_name, asn1_name in zip(nss_names, asn1_names): > + name_type = nss_name.type_string > + if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: > + name = _decode_krb5principalname(asn1_name['otherName']['value']) > + else: > + name = nss_name.name > + names.append((name_type, name)) > + > + return names > + > + > if __name__ == '__main__': > # this can be run with: > # python ipalib/x509.py < /etc/ipa/ca.crt > diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py > index 06041d3083565e8d093b610473d6083111d406d2..85be2cf4daeb282b2c2ba866017c8e5745abda6d 100644 > --- a/ipaserver/plugins/cert.py > +++ b/ipaserver/plugins/cert.py > @@ -535,7 +535,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): > > # Validate the subject alt name, if any > for name_type, name in subjectaltname: > - if name_type == pkcs10.SAN_DNSNAME: > + if name_type == x509.SAN_DNSNAME: > name = unicode(name) > alt_principal_obj = None > alt_principal_string = unicode(principal) > @@ -566,13 +566,13 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): > "with subject alt name '%s'.") % name) > if alt_principal_string is not None and not bypass_caacl: > caacl_check(principal_type, principal, ca, profile_id) > - elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, > - pkcs10.SAN_OTHERNAME_UPN): > + elif name_type in (x509.SAN_OTHERNAME_KRB5PRINCIPALNAME, > + x509.SAN_OTHERNAME_UPN): > if name != principal_string: > raise errors.ACIError( > info=_("Principal '%s' in subject alt name does not " > "match requested principal") % name) > - elif name_type == pkcs10.SAN_RFC822NAME: > + elif name_type == x509.SAN_RFC822NAME: > if principal_type == USER: > if name not in principal_obj.get('mail', []): > raise errors.ValidationError( > -- > 2.5.5 > > From 27a31d28a0af4a84545678f72ae86946dc9ebeaf Mon Sep 17 00:00:00 2001 > From: Fraser Tweedale > Date: Fri, 22 Jul 2016 12:05:13 +1000 > Subject: [PATCH 93/94] x509: fix SAN directoryName parsing > > The subjectAltName extension parsing code in ipalib.x509 fails on > directoryName values because the Choice structure is not endowed > with an inner type. Implement the Name structure, whose inner type > is a CHOICE { SEQUENCE OF RelativeDistinguishedName }, to resolve. > > Note that the structure still does not get fully parsed; only enough > to recognise the SequenceOf tag and not fail. > > Part of: https://fedorahosted.org/freeipa/ticket/6022 > --- > ipalib/x509.py | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/ipalib/x509.py b/ipalib/x509.py > index 15168de08240a84794efef409d022eaa983291c9..2dc67441c92686826dd24f00a5ad30566cd032da 100644 > --- a/ipalib/x509.py > +++ b/ipalib/x509.py > @@ -196,6 +196,12 @@ def is_self_signed(certificate, datatype=PEM, dbdir=None): > del nsscert > return self_signed > > +class _Name(univ.Choice): > + componentType = namedtype.NamedTypes( > + namedtype.NamedType('rdnSequence', > + univ.SequenceOf()), > + ) > + > class _TBSCertificate(univ.Sequence): > componentType = namedtype.NamedTypes( > namedtype.NamedType( > @@ -204,9 +210,9 @@ class _TBSCertificate(univ.Sequence): > tag.tagClassContext, tag.tagFormatSimple, 0))), > namedtype.NamedType('serialNumber', univ.Integer()), > namedtype.NamedType('signature', univ.Sequence()), > - namedtype.NamedType('issuer', univ.Sequence()), > + namedtype.NamedType('issuer', _Name()), > namedtype.NamedType('validity', univ.Sequence()), > - namedtype.NamedType('subject', univ.Sequence()), > + namedtype.NamedType('subject', _Name()), > namedtype.NamedType('subjectPublicKeyInfo', univ.Sequence()), > namedtype.OptionalNamedType( > 'issuerUniquedID', > @@ -403,7 +409,7 @@ class _GeneralName(univ.Choice): > namedtype.NamedType('x400Address', univ.Sequence().subtype( > implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) > ), > - namedtype.NamedType('directoryName', univ.Choice().subtype( > + namedtype.NamedType('directoryName', _Name().subtype( > implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) > ), > namedtype.NamedType('ediPartyName', univ.Sequence().subtype( > -- > 2.5.5 > > From 6e8dac22d4a985ce344c0d8583260cf5ceccbc1b Mon Sep 17 00:00:00 2001 > From: Fraser Tweedale > Date: Fri, 22 Jul 2016 12:11:59 +1000 > Subject: [PATCH 94/94] x509: use NSS enums and OIDs to identify SAN types > > GeneralName parsing currently relies heavily on strings from NSS. > Make the code hopefully less brittle by identifying GeneralName > types by NSS enums and, for otherName, the name-type OID also. > > Part of: https://fedorahosted.org/freeipa/ticket/6022 > --- > ipalib/x509.py | 30 +++++++++++++++++++++++------- > ipaserver/plugins/cert.py | 19 ++++++++++--------- > 2 files changed, 33 insertions(+), 16 deletions(-) > > diff --git a/ipalib/x509.py b/ipalib/x509.py > index 2dc67441c92686826dd24f00a5ad30566cd032da..541609fbc1a53a73eafcff2327e53a292c2d9a3c 100644 > --- a/ipalib/x509.py > +++ b/ipalib/x509.py > @@ -33,6 +33,7 @@ > > from __future__ import print_function > > +import collections > import os > import sys > import base64 > @@ -63,10 +64,8 @@ EKU_EMAIL_PROTECTION = '1.3.6.1.5.5.7.3.4' > EKU_ANY = '2.5.29.37.0' > EKU_PLACEHOLDER = '1.3.6.1.4.1.3319.6.10.16' > > -SAN_DNSNAME = 'DNS name' > -SAN_RFC822NAME = 'RFC822 Name' > -SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' > -SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' > +SAN_UPN = '1.3.6.1.4.1.311.20.2.3' > +SAN_KRB5PRINCIPALNAME = '1.3.6.1.5.2.2' > > _subject_base = None > > @@ -465,6 +464,10 @@ def _decode_krb5principalname(data): > return name > > > +GeneralNameInfo = collections.namedtuple( > + 'GeneralNameInfo', ('type', 'desc', 'value')) > + > + > def decode_generalnames(secitem): > """ > Decode a GeneralNames object (this the data for the Subject > @@ -482,12 +485,25 @@ def decode_generalnames(secitem): > asn1_names = decoder.decode(secitem.data, asn1Spec=_SubjectAltName())[0] > names = [] > for nss_name, asn1_name in zip(nss_names, asn1_names): > - name_type = nss_name.type_string > - if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: > + # NOTE: we use the NSS enum to identify the name type. > + # (For otherName we also tuple it up with the type-id OID). > + # The enum does not correspond exactly to the ASN.1 tags. > + # If we ever want to switch to using the true tag numbers, > + # the expression to get the tag is: > + # > + # asn1_name.getComponent().getTagSet()[0].asTuple()[2] > + # > + if nss_name.type_enum == nss.certOtherName: > + oid = str(asn1_name['otherName']['type-id']) > + nametype = (nss_name.type_enum, oid) > + else: > + nametype = nss_name.type_enum > + > + if nametype == (nss.certOtherName, SAN_KRB5PRINCIPALNAME): > name = _decode_krb5principalname(asn1_name['otherName']['value']) > else: > name = nss_name.name > - names.append((name_type, name)) > + names.append(GeneralNameInfo(nametype, nss_name.type_string, name)) > > return names > > diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py > index 85be2cf4daeb282b2c2ba866017c8e5745abda6d..207f6964645254ebc417cab80634a68911ae0a08 100644 > --- a/ipaserver/plugins/cert.py > +++ b/ipaserver/plugins/cert.py > @@ -534,8 +534,8 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): > "to the 'userCertificate' attribute of entry '%s'.") % dn) > > # Validate the subject alt name, if any > - for name_type, name in subjectaltname: > - if name_type == x509.SAN_DNSNAME: > + for name_type, desc, name in subjectaltname: > + if name_type == nss.certDNSName: > name = unicode(name) > alt_principal_obj = None > alt_principal_string = unicode(principal) > @@ -549,7 +549,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): > raise errors.ValidationError( > name='csr', > error=_("subject alt name type %s is forbidden " > - "for user principals") % name_type > + "for user principals") % desc > ) > except errors.NotFound: > # We don't want to issue any certificates referencing > @@ -566,13 +566,15 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): > "with subject alt name '%s'.") % name) > if alt_principal_string is not None and not bypass_caacl: > caacl_check(principal_type, principal, ca, profile_id) > - elif name_type in (x509.SAN_OTHERNAME_KRB5PRINCIPALNAME, > - x509.SAN_OTHERNAME_UPN): > + elif name_type in [ > + (nss.certOtherName, x509.SAN_UPN), > + (nss.certOtherName, x509.SAN_KRB5PRINCIPALNAME), > + ]: > if name != principal_string: > raise errors.ACIError( > info=_("Principal '%s' in subject alt name does not " > "match requested principal") % name) > - elif name_type == x509.SAN_RFC822NAME: > + elif name_type == nss.certRFC822Name: > if principal_type == USER: > if name not in principal_obj.get('mail', []): > raise errors.ValidationError( > @@ -585,12 +587,11 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): > raise errors.ValidationError( > name='csr', > error=_("subject alt name type %s is forbidden " > - "for non-user principals") % name_type > + "for non-user principals") % desc > ) > else: > raise errors.ACIError( > - info=_("Subject alt name type %s is forbidden") % > - name_type) > + info=_("Subject alt name type %s is forbidden") % desc) > > # Request the certificate > result = self.Backend.ra.request_certificate( > -- > 2.5.5 > > From 9481e0436dc46b4668f1a45bd21f97c2096da142 Mon Sep 17 00:00:00 2001 > From: Fraser Tweedale > Date: Mon, 15 Aug 2016 15:39:49 +1000 > Subject: [PATCH] x509: include otherName DER value in GeneralNameInfo > > We want to include the whole DER value when we pretty-print > unrecognised otherNames, so add a field to the GeneralNameInfo > namedtuple and populate it for otherNames. > > Part of: https://fedorahosted.org/freeipa/ticket/6022 > --- > ipalib/x509.py | 13 +++++++++---- > ipaserver/plugins/cert.py | 2 +- > 2 files changed, 10 insertions(+), 5 deletions(-) > > diff --git a/ipalib/x509.py b/ipalib/x509.py > index 541609fbc1a53a73eafcff2327e53a292c2d9a3c..e986a97a58aafd3aeab08765a397edbf67c7841a 100644 > --- a/ipalib/x509.py > +++ b/ipalib/x509.py > @@ -465,7 +465,7 @@ def _decode_krb5principalname(data): > > > GeneralNameInfo = collections.namedtuple( > - 'GeneralNameInfo', ('type', 'desc', 'value')) > + 'GeneralNameInfo', ('type', 'desc', 'value', 'der_value')) > > > def decode_generalnames(secitem): > @@ -477,8 +477,9 @@ def decode_generalnames(secitem): > The input is the DER-encoded extension data, without the > OCTET STRING header, as an nss SecItem object. > > - Return a list of tuples of name types (as string, suitable for > - presentation) and names (as string, suitable for presentation). > + Return a list of ``GeneralNameInfo`` namedtuples. The > + ``der_value`` field is set for otherNames, otherwise it is > + ``None``. > > """ > nss_names = nss.x509_alt_name(secitem, repr_kind=nss.AsObject) > @@ -496,14 +497,18 @@ def decode_generalnames(secitem): > if nss_name.type_enum == nss.certOtherName: > oid = str(asn1_name['otherName']['type-id']) > nametype = (nss_name.type_enum, oid) > + der_value = asn1_name['otherName']['value'].asOctets() > else: > nametype = nss_name.type_enum > + der_value = None > > if nametype == (nss.certOtherName, SAN_KRB5PRINCIPALNAME): > name = _decode_krb5principalname(asn1_name['otherName']['value']) > else: > name = nss_name.name > - names.append(GeneralNameInfo(nametype, nss_name.type_string, name)) > + > + gni = GeneralNameInfo(nametype, nss_name.type_string, name, der_value) > + names.append(gni) > > return names > > diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py > index 207f6964645254ebc417cab80634a68911ae0a08..30c708113942fca4d1f11aa1219367110e518309 100644 > --- a/ipaserver/plugins/cert.py > +++ b/ipaserver/plugins/cert.py > @@ -534,7 +534,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): > "to the 'userCertificate' attribute of entry '%s'.") % dn) > > # Validate the subject alt name, if any > - for name_type, desc, name in subjectaltname: > + for name_type, desc, name, der_name in subjectaltname: > if name_type == nss.certDNSName: > name = unicode(name) > alt_principal_obj = None > -- > 2.5.5 > > From 0706141a0457a90e58c94527c65d7f1ead87c719 Mon Sep 17 00:00:00 2001 > From: Fraser Tweedale > Date: Thu, 14 Jul 2016 21:36:33 +1000 > Subject: [PATCH] cert-show: show subject alternative names > > Enhance the cert-show command to return subject alternative name > values. > > Fixes: https://fedorahosted.org/freeipa/ticket/6022 > --- > ipaserver/plugins/cert.py | 125 ++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 120 insertions(+), 5 deletions(-) > > diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py > index 30c708113942fca4d1f11aa1219367110e518309..c42ba2de06df5d6204275fb9d31694268814a269 100644 > --- a/ipaserver/plugins/cert.py > +++ b/ipaserver/plugins/cert.py > @@ -38,7 +38,7 @@ from ipalib import ngettext > from ipalib.constants import IPA_CA_CN > from ipalib.crud import Create, PKQuery, Retrieve, Search > from ipalib.frontend import Method, Object > -from ipalib.parameters import Bytes, DateTime, DNParam, Principal > +from ipalib.parameters import Bytes, DateTime, DNParam, DNSNameParam, Principal > from ipalib.plugable import Registry > from .virtual import VirtualCommand > from .baseldap import pkey_to_value > @@ -49,6 +49,7 @@ from ipalib.request import context > from ipalib import output > from ipapython import kerberos > from ipapython.dn import DN > +from ipapython.ipa_log_manager import root_logger > from ipaserver.plugins.service import normalize_principal, validate_realm > > if six.PY3: > @@ -293,9 +294,74 @@ class BaseCertObject(Object): > label=_('Serial number (hex)'), > flags={'no_create', 'no_update', 'no_search'}, > ), > + Str( > + 'san_rfc822name*', > + label=_('Subject Alternative Name (Email)'), > + flags={'no_create', 'no_update', 'no_search'}, > + ), > + DNSNameParam( > + 'san_dnsname*', > + label=_('Subject Alternative Name (DNS)'), > + flags={'no_create', 'no_update', 'no_search'}, > + ), > + Str( > + 'san_x400address*', > + label=_('Subject Alternative Name (X.400 address)'), > + flags={'no_create', 'no_update', 'no_search'}, > + ), > + Str( > + 'san_directoryname*', > + label=_('Subject Alternative Name (Directory name)'), > + flags={'no_create', 'no_update', 'no_search'}, > + ), > + Str( > + 'san_edipartyname*', > + label=_('Subject Alternative Name (EDI Party name)'), > + flags={'no_create', 'no_update', 'no_search'}, > + ), > + Str( > + 'san_uri*', > + label=_('Subject Alternative Name (URI)'), > + flags={'no_create', 'no_update', 'no_search'}, > + ), > + Str( > + 'san_ipaddress*', > + label=_('Subject Alternative Name (IP Address)'), > + flags={'no_create', 'no_update', 'no_search'}, > + ), > + Str( > + 'san_oid*', > + label=_('Subject Alternative Name (OID)'), > + flags={'no_create', 'no_update', 'no_search'}, > + ), > + Principal( > + 'san_other_upn*', > + label=_('Subject Alternative Name (UPN)'), > + flags={'no_create', 'no_update', 'no_search'}, > + ), > + Principal( > + 'san_other_kpn*', > + label=_('Subject Alternative Name (Kerberos Principal)'), > + flags={'no_create', 'no_update', 'no_search'}, > + ), > + Str( > + 'san_other*', > + label=_('Subject Alternative Name (Other Name)'), > + flags={'no_create', 'no_update', 'no_search'}, > + ), > ) > > - def _parse(self, obj): > + def _parse(self, obj, generic_othernames): > + """Extract certificate-specific data into a result object. > + > + ``obj`` > + Result object containing certificate, into which extracted > + data will be inserted. > + ``generic_othernames`` > + If ``True`` add recognised otherNames to the generic > + ``san_other`` attribute as well as their own attribute. > + > + """ > cert = x509.load_certificate(obj['certificate']) > obj['subject'] = DN(unicode(cert.subject)) > obj['issuer'] = DN(unicode(cert.issuer)) > @@ -308,6 +374,55 @@ class BaseCertObject(Object): > obj['serial_number'] = cert.serial_number > obj['serial_number_hex'] = u'0x%X' % cert.serial_number > > + try: > + ext_san = cert.get_extension(nss.SEC_OID_X509_SUBJECT_ALT_NAME) > + general_names = x509.decode_generalnames(ext_san.value) > + except KeyError: > + general_names = [] > + > + for name_type, desc, name, der_name in general_names: > + try: > + self._add_san_attribute( > + obj, generic_othernames, name_type, name, der_name) > + except Exception as e: > + # Invalid GeneralName (i.e. not a valid X.509 cert); > + # don't fail but log something about it > + root_logger.warning( > + "Encountered bad GeneralName; skipping", exc_info=True) > + > + > + def _add_san_attribute( > + self, obj, generic_othernames, name_type, name, der_name): > + name_type_map = { > + nss.certRFC822Name: 'san_rfc822name', > + nss.certDNSName: 'san_dnsname', > + nss.certX400Address: 'san_x400address', > + nss.certDirectoryName: 'san_directoryname', > + nss.certEDIPartyName: 'san_edipartyname', > + nss.certURI: 'san_uri', > + nss.certIPAddress: 'san_ipaddress', > + nss.certRegisterID: 'san_oid', > + (nss.certOtherName, x509.SAN_UPN): 'san_other_upn', > + (nss.certOtherName, x509.SAN_KRB5PRINCIPALNAME): 'san_other_kpn', > + } > + > + attr_name = name_type_map.get(name_type, 'san_other') > + > + if attr_name != 'san_other': > + name_formatted = name > + else: > + # display as "OID : b64(DER)" > + name_formatted = u'{}:{}'.format( > + name_type[1], base64.b64encode(der_name)) > + attr_value = self.params[attr_name].type(name_formatted) > + obj.setdefault(attr_name, []).append(attr_value) > + > + if generic_othernames and attr_name.startswith('san_other_'): > + # recurse, faking the name type so that OID is still conveyed, > + # but it won't be found in name_type_map > + self._add_san_attribute( > + obj, False, (None, name_type[1]), name, der_name) > + > > class BaseCertMethod(Method): > def get_options(self): > @@ -597,7 +712,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): > result = self.Backend.ra.request_certificate( > csr, profile_id, ca_id, request_type=request_type) > if not raw: > - self.obj._parse(result) > + self.obj._parse(result, all) > result['request_id'] = int(result['request_id']) > > # Success? Then add it to the principal's entry > @@ -775,7 +890,7 @@ class cert_show(Retrieve, CertMethod, VirtualCommand): > > if not raw: > result['certificate'] = result['certificate'].replace('\r\n', '') > - self.obj._parse(result) > + self.obj._parse(result, all) > result['revoked'] = ('revocation_reason' in result) > if 'owner' in result: > self.obj._fill_owners(result) > @@ -1143,7 +1258,7 @@ class cert_find(Search, CertMethod): > if 'certificate' in obj: > obj['certificate'] = ( > obj['certificate'].replace('\r\n', '')) > - self.obj._parse(obj) > + self.obj._parse(obj, all) > if not all: > del obj['certificate'] > del obj['valid_not_before'] > -- > 2.5.5 > From ftweedal at redhat.com Fri Aug 19 11:11:56 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 19 Aug 2016 21:11:56 +1000 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <20160816140939.GV23927@dhcp-40-8.bne.redhat.com> References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> <885c4c72-6e8a-4220-b25e-f577612368d2@redhat.com> <20160809144716.GA23927@dhcp-40-8.bne.redhat.com> <20160816052401.GR23927@dhcp-40-8.bne.redhat.com> <7ad5a28f-9670-b76a-f100-1a6681ac52e5@redhat.com> <20160816140939.GV23927@dhcp-40-8.bne.redhat.com> Message-ID: <20160819111156.GQ3877@dhcp-40-8.bne.redhat.com> Bump for review. On Wed, Aug 17, 2016 at 12:09:39AM +1000, Fraser Tweedale wrote: > On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: > > On 16.8.2016 07:24, Fraser Tweedale wrote: > > > On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > > > > On 9.8.2016 16:47, Fraser Tweedale wrote: > > > > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > > > > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > > > > Please review the attached patch with adds --certificate-out and > > > > > > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > > > > > > > > > > > Note that --certificate-chain-out currently writes a bogus file due > > > > > > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > > > > > > > 1) The client-side *-out options should be defined on the client side, not > > > > > > > > on the server side. > > > > > > > > > > > > > > > Will option defined on client side be propagated to, and observable > > > > > > > in the ipaserver plugin? The ipaserver plugin needs to observe that > > > > > > > *-out has been requested and executes additional command(s) on that > > > > > > > basis. > > > > > > > > > > > > Is there a reason not to *always* return the certs? > > > > > > > > > > > We hit Dogtag to retrieve them. > > > > > > > > I don't think that's an issue in a -show command. > > > > > > > cert_show is invoked by other commands (cert_find*, cert_show, > > > cert_request, cert_status, ca_del) but these all hit Dogtag anyway > > > so I suppose that's fine. I'll return the cert *and* the chain in > > > separate attributes, unconditionally. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) I don't think there should be additional information included in summary > > > > > > > > (and it definitely should not be multi-line). I would rather inform the user > > > > > > > > via an error message when unable to write the files. > > > > > > > > > > > > > > > I was just following the pattern of other commands that write certs, > > > > > > > profile config, etc. Apart from consistency with other commands I > > > > > > > agree that there is no need to have it. So I will remove it. > > > > > > > > > > > > > > > If you think there is an actual value in informing the user about > > > > > > > > successfully writing the files, please use ipalib.messages for the job. > > > > > > > > > > > > > > > > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 would be > > > > > > > > concatenated PEM, as that's the most commonly used format in IPA (in > > > > > > > > installers, there are no cert chains in API commands ATM). > > > > > > > > > > > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > > > > > > or concatenated PEMs, but sometimes they must be concatenated > > > > > > > forward, and othertimes backwards. There is no one size fits all. > > > > > > > > > > > > True, which is exactly why I think we should at least be self-consistent and > > > > > > use concatenated PEM (and multi-value DER over the wire). > > > > > > > > > > > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept > > > > > header). > > > > > > > > > > If we want list-of-PEMs between server and client we have to convert > > > > > on the server. Do we have a good way of doing this without exec'ing > > > > > `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' > > > > > to do the conversion on the server? python-nss does not have PKCS7 > > > > > functions and I am not keen on adding a pyasn1 PKCS7 parser just for > > > > > the sake of pushing bits as list-of-PEMs. > > > > > > > > I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other. > > > > For example, if we added a call to retrieve external CA chain using certs > > > > from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to > > > > PKCS#7 if it was our cert chain format of choice. > > > > > > > > What we can avoid though is executing "openssl pkcs7" to do the conversion - > > > > we can use an approach similar to our DNSSEC code and use python-cffi to > > > > call libcrypto's PKCS#7 conversion routines instead. > > > > > > > I had a look at the OpenSSL API for parsing PKCS #7; now I prefer to > > > exec `openssl' to do the job :) > > > > > > I will transmit DER-encoded PKCS #7 object on the wire; we cannot > > > used multi-valued DER attribute because order is important. Client > > > will convert to PEMs. > > > > Well, my point was not to send PKCS#7 over the wire, so that clients > > (including 3rd party clients) do not have to convert from PKCS#7 themselves. > > > > In fact we can use multi-valued DER - whatever you send over the wire from > > the server will be received in the exact same order by the client. Even if > > it wasn't, you can easily restore the order by matching issuer and subject > > names of the certificates. > > > > > > > > Should have new patch on list this afternoon. > > > > > > Thanks, > > > Fraser > > > > > > > > > > > > > FWIW, man pages and code suggest that PKCS #7 is accepted in > > > > > installer, etc. > > > > > > > > True, but that's a relatively new feature (since 4.1) and the installer > > > > internally executes "openssl pkcs7" to convert PKCS #7 to list of certs :-) > > > > > > > > > > > > > > > > We can add an option to control the format later, but for now, > > > > > > > Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst > > > > > > > case is an admin has to invoke `openssl pkcs7' and concat the certs > > > > > > > themselves. > > > > > > > > > > > > AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, > > > > > > so I'm afraid the worst case would happen virtually always. > > > > > > > > > > > If you're OK with invoking OpenSSL on the client to convert PKCS #7 > > > > > to list-of-PEMs (similar to what is done in > > > > > ipapython.certdb.NSSDatabase) then we can have the client perform > > > > > the conversion. > > > > > > > > See above. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4) Over the wire, the certs should be DER-formatted, as that's the most > > > > > > > > common wire format in other API commands. > > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > > > > > > > > 5) What is the benefit in having the CA cert and the rest of the chain > > > > > > > > separate? For end-entity certs it makes sense to separate the cert from the > > > > > > > > CA chain, but for CA certs, you usually want the full chain, no? > > > > > > > > > > > > > > > If you want to anchor trust directly at a subca (e.g. restrict VPN > > > > > > > login to certs issued by VPN sub-CA) then you often just want the > > > > > > > cert. The chain option does subsume it, at cost of more work for > > > > > > > administrators with this use case. I think it makes sense to keep > > > > > > > both options. > > > > > > > > > > > > Does it? From what you described above, you either want just the sub-CA > > > > > > cert, or the full chain including the sub-CA cert, in which case it might > > > > > > make more sense to have a single --out option and a --chain flag. > > > > > > > > > > > How about --certificate-out which defaults to single cert, but does > > > > > chain (as list-of-PEMs) when --chain flag given. > > > > > > > > > > Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more > > > > > `--out' options. > > > > > > > > +1 > > > > > Updated patch 0097-2 attached, and new patch 0099 which must be > applied first. > > I have implemented the suggested changes, except for cffi (I execute > `openssl pkcs7' instead). > > There are two new output attributes on the wire, 'certificate' > (single-value DER X.509), and 'certificate_chain' (ordered > multi-value DER X.509). They are always returned. The first cert > in the chain is always the same as 'certificate'; obviously this is > redunant but I have left it this way because I think usage is > clearer. > > Thanks, > Fraser > From 77d7d0185bcf3cb86f56bd128507a8e2cfedc775 Mon Sep 17 00:00:00 2001 > From: Fraser Tweedale > Date: Tue, 16 Aug 2016 13:16:58 +1000 > Subject: [PATCH] Add function for extracting PEM certs from PKCS #7 > > Add a single function for extracting X.509 certs in PEM format from > a PKCS #7 object. Refactor sites that execute ``openssl pkcs7`` to > use the new function. > > Part of: https://fedorahosted.org/freeipa/ticket/6178 > --- > ipalib/x509.py | 21 ++++++++++++++++- > ipapython/certdb.py | 14 ++++------- > ipaserver/install/cainstance.py | 52 +++++++++++++++-------------------------- > 3 files changed, 43 insertions(+), 44 deletions(-) > > diff --git a/ipalib/x509.py b/ipalib/x509.py > index 82194922d151a1b0f2df03df3578ad45b43b71c9..782519ce45e05e09d4dc02d41a537daab84db9e4 100644 > --- a/ipalib/x509.py > +++ b/ipalib/x509.py > @@ -50,11 +50,12 @@ from ipalib import util > from ipalib import errors > from ipaplatform.paths import paths > from ipapython.dn import DN > +from ipapython import ipautil > > PEM = 0 > DER = 1 > > -PEM_REGEX = re.compile(r'(?<=-----BEGIN CERTIFICATE-----).*?(?=-----END CERTIFICATE-----)', re.DOTALL) > +PEM_REGEX = re.compile(r'-----BEGIN CERTIFICATE-----.*?-----END CERTIFICATE-----', re.DOTALL) > > EKU_SERVER_AUTH = '1.3.6.1.5.5.7.3.1' > EKU_CLIENT_AUTH = '1.3.6.1.5.5.7.3.2' > @@ -144,6 +145,24 @@ def load_certificate_list(data, dbdir=None): > certs = [load_certificate(cert, PEM, dbdir) for cert in certs] > return certs > > + > +def pkcs7_to_pems(data, datatype=PEM): > + """ > + Extract certificates from a PKCS #7 object. > + > + Return a ``list`` of X.509 PEM strings. > + > + May throw ``ipautil.CalledProcessError`` on invalid data. > + > + """ > + cmd = [ > + paths.OPENSSL, "pkcs7", "-print_certs", > + "-inform", "PEM" if datatype == PEM else "DER", > + ] > + result = ipautil.run(cmd, stdin=data, capture_output=True) > + return PEM_REGEX.findall(result.output) > + > + > def load_certificate_list_from_file(filename, dbdir=None): > """ > Load a certificate list from a PEM file. > diff --git a/ipapython/certdb.py b/ipapython/certdb.py > index e19f712d82f160ebc5de9c5b8d6627cb941c2cef..fd18023794a2daace60efd97aff54180b8409bbd 100644 > --- a/ipapython/certdb.py > +++ b/ipapython/certdb.py > @@ -270,13 +270,11 @@ class NSSDatabase(object): > continue > > if label in ('PKCS7', 'PKCS #7 SIGNED DATA', 'CERTIFICATE'): > - args = [ > - paths.OPENSSL, 'pkcs7', > - '-print_certs', > - ] > try: > - result = ipautil.run( > - args, stdin=body, capture_output=True) > + certs = x509.pkcs7_to_pems(body) > + extracted_certs += '\n'.join(certs) + '\n' > + loaded = True > + continue > except ipautil.CalledProcessError as e: > if label == 'CERTIFICATE': > root_logger.warning( > @@ -287,10 +285,6 @@ class NSSDatabase(object): > "Skipping PKCS#7 in %s at line %s: %s", > filename, line, e) > continue > - else: > - extracted_certs += result.output + '\n' > - loaded = True > - continue > > if label in ('PRIVATE KEY', 'ENCRYPTED PRIVATE KEY', > 'RSA PRIVATE KEY', 'DSA PRIVATE KEY', > diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py > index 070498fe8a394802ea55f848a268e2b6563ec472..12c973c8acdcb0e657d92695dc28043b29966f2c 100644 > --- a/ipaserver/install/cainstance.py > +++ b/ipaserver/install/cainstance.py > @@ -839,44 +839,30 @@ class CAInstance(DogtagInstance): > # makes openssl throw up. > data = base64.b64decode(chain) > > - result = ipautil.run( > - [paths.OPENSSL, > - "pkcs7", > - "-inform", > - "DER", > - "-print_certs", > - ], stdin=data, capture_output=True) > - certlist = result.output > + certlist = x509.pkcs7_to_pems(data, x509.DER) > > # Ok, now we have all the certificates in certs, walk through it > # and pull out each certificate and add it to our database > > - st = 1 > - en = 0 > - subid = 0 > ca_dn = DN(('CN','Certificate Authority'), self.subject_base) > - while st > 0: > - st = certlist.find('-----BEGIN', en) > - en = certlist.find('-----END', en+1) > - if st > 0: > - try: > - (chain_fd, chain_name) = tempfile.mkstemp() > - os.write(chain_fd, certlist[st:en+25]) > - os.close(chain_fd) > - (_rdn, subject_dn) = certs.get_cert_nickname(certlist[st:en+25]) > - if subject_dn == ca_dn: > - nick = get_ca_nickname(self.realm) > - trust_flags = 'CT,C,C' > - else: > - nick = str(subject_dn) > - trust_flags = ',,' > - self.__run_certutil( > - ['-A', '-t', trust_flags, '-n', nick, '-a', > - '-i', chain_name] > - ) > - finally: > - os.remove(chain_name) > - subid += 1 > + for cert in certlist: > + try: > + (chain_fd, chain_name) = tempfile.mkstemp() > + os.write(chain_fd, cert) > + os.close(chain_fd) > + (_rdn, subject_dn) = certs.get_cert_nickname(cert) > + if subject_dn == ca_dn: > + nick = get_ca_nickname(self.realm) > + trust_flags = 'CT,C,C' > + else: > + nick = str(subject_dn) > + trust_flags = ',,' > + self.__run_certutil( > + ['-A', '-t', trust_flags, '-n', nick, '-a', > + '-i', chain_name] > + ) > + finally: > + os.remove(chain_name) > > def __request_ra_certificate(self): > # Create a noise file for generating our private key > -- > 2.5.5 > > From 4779e2cd4c30b896dbe914c095c0dbc068e38b63 Mon Sep 17 00:00:00 2001 > From: Fraser Tweedale > Date: Mon, 8 Aug 2016 14:27:20 +1000 > Subject: [PATCH] Add options to write lightweight CA cert or chain to file > > Administrators need a way to retrieve the certificate or certificate > chain of an IPA-managed lightweight CA. Add output attributes to > `ca_show' containing the CA certificate and chain (as multiple DER > values), and add the `--certificate-out' option and `--chain' flag > as client-side options for writing one or the other to a file. > > Fixes: https://fedorahosted.org/freeipa/ticket/6178 > --- > ipaclient/plugins/ca.py | 47 +++++++++++++++++++++++++++++++++++++++++++++ > ipaserver/plugins/ca.py | 34 ++++++++++++++++++++++++++++---- > ipaserver/plugins/dogtag.py | 12 ++++++++++++ > 3 files changed, 89 insertions(+), 4 deletions(-) > create mode 100644 ipaclient/plugins/ca.py > > diff --git a/ipaclient/plugins/ca.py b/ipaclient/plugins/ca.py > new file mode 100644 > index 0000000000000000000000000000000000000000..63770ff42af10f3f7d9419b692107433ddb35198 > --- /dev/null > +++ b/ipaclient/plugins/ca.py > @@ -0,0 +1,47 @@ > +# > +# Copyright (C) 2016 FreeIPA Contributors see COPYING for license > +# > + > +import base64 > +from ipaclient.frontend import MethodOverride > +from ipalib import util, x509, Flag, Str > +from ipalib.plugable import Registry > +from ipalib.text import _ > + > +register = Registry() > + > + > + at register(override=True, no_fail=True) > +class ca_show(MethodOverride): > + > + takes_options = ( > + Str('certificate_out?', > + doc=_('Write certificate to file'), > + include='cli', > + ), > + Flag('chain', > + default=False, > + doc=_('Write certificate chain instead of single certificate'), > + include='cli', > + ), > + ) > + > + def forward(self, *keys, **options): > + filename = None > + if 'certificate_out' in options: > + filename = options.pop('certificate_out') > + util.check_writable_file(filename) > + chain = options.pop('chain', False) > + > + result = super(ca_show, self).forward(*keys, **options) > + if filename: > + to_pem = lambda x: x509.make_pem(base64.b64encode(x)) > + if chain: > + ders = result['result']['certificate_chain'] > + data = '\n'.join(map(to_pem, ders)) > + else: > + data = to_pem(result['result']['certificate']) > + with open(filename, 'wb') as f: > + f.write(data) > + > + return result > diff --git a/ipaserver/plugins/ca.py b/ipaserver/plugins/ca.py > index 966ae2b1bdb4bb0207dfa58f0e9c951bc930f766..2e1787707bf002455478c969cd1914692c743b9c 100644 > --- a/ipaserver/plugins/ca.py > +++ b/ipaserver/plugins/ca.py > @@ -2,14 +2,14 @@ > # Copyright (C) 2016 FreeIPA Contributors see COPYING for license > # > > -from ipalib import api, errors, DNParam, Str > +from ipalib import api, errors, Bytes, DNParam, Str > from ipalib.constants import IPA_CA_CN > from ipalib.plugable import Registry > from ipaserver.plugins.baseldap import ( > LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, > LDAPUpdate, LDAPRetrieve) > from ipaserver.plugins.cert import ca_enabled_check > -from ipalib import _, ngettext > +from ipalib import _, ngettext, x509 > > > __doc__ = _(""" > @@ -140,9 +140,35 @@ class ca_find(LDAPSearch): > class ca_show(LDAPRetrieve): > __doc__ = _("Display the properties of a CA.") > > - def execute(self, *args, **kwargs): > + has_output_params = LDAPRetrieve.has_output_params + ( > + Bytes( > + 'certificate', > + label=_("Certificate"), > + doc=_("X.509 certificate"), > + flags={'no_display'}, > + ), > + Bytes( > + 'certificate_chain*', > + label=_("Certificate chain"), > + doc=_("PKCS #7 certificate chain"), > + flags={'no_display'}, > + ), > + ) > + > + def execute(self, *keys, **options): > ca_enabled_check() > - return super(ca_show, self).execute(*args, **kwargs) > + result = super(ca_show, self).execute(*keys, **options) > + > + ca_id = result['result']['ipacaid'][0] > + with self.api.Backend.ra_lightweight_ca as ca_api: > + result['result']['certificate'] = ca_api.read_ca_cert(ca_id) > + > + pkcs7_der = ca_api.read_ca_chain(ca_id) > + pems = x509.pkcs7_to_pems(pkcs7_der, x509.DER) > + ders = (x509.normalize_certificate(pem) for pem in pems) > + result['result']['certificate_chain'] = list(ders) > + > + return result > > > @register() > diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py > index aef1e888eb1b6c273c1fd12cbf4912407f8f8132..1fd3106e0ae723eb30dbe32c61e637790f6085d2 100644 > --- a/ipaserver/plugins/dogtag.py > +++ b/ipaserver/plugins/dogtag.py > @@ -2205,6 +2205,18 @@ class ra_lightweight_ca(RestClient): > except: > raise errors.RemoteRetrieveError(reason=_("Response from CA was not valid JSON")) > > + def read_ca_cert(self, ca_id): > + status, resp_headers, resp_body = self._ssldo( > + 'GET', '{}/cert'.format(ca_id), > + headers={'Accept': 'application/pkix-cert'}) > + return resp_body > + > + def read_ca_chain(self, ca_id): > + status, resp_headers, resp_body = self._ssldo( > + 'GET', '{}/chain'.format(ca_id), > + headers={'Accept': 'application/pkcs7-mime'}) > + return resp_body > + > def disable_ca(self, ca_id): > self._ssldo( > 'POST', ca_id + '/disable', > -- > 2.5.5 > From tkrizek at redhat.com Fri Aug 19 12:09:16 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Fri, 19 Aug 2016 14:09:16 +0200 Subject: [Freeipa-devel] [PATCH] 0004 Fix ipa-server-install in pure IPv6 environment Message-ID: Hi, please review the attached patch. Make sure the hostname isn't resolved to link local IPv6(feXX:...) during testing, which doesn't work (and isn't supposed to). -- Tomas Krizek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tkrizek-0004-Fix-ipa-server-install-in-pure-IPv6-environment.patch Type: text/x-patch Size: 1212 bytes Desc: not available URL: From mbasti at redhat.com Fri Aug 19 13:22:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Aug 2016 15:22:00 +0200 Subject: [Freeipa-devel] [PATCH 0214] Support schema files for external plugins In-Reply-To: <20160819094345.ioyyoujpps2gkpfj@redhat.com> References: <20160808093459.ivfpnh5femnqf7mi@redhat.com> <20160808102626.ve3ubsyhjiotpzcp@redhat.com> <20160808111248.3kpuzprcwxksfmgr@redhat.com> <20160819094345.ioyyoujpps2gkpfj@redhat.com> Message-ID: On 19.08.2016 11:43, Alexander Bokovoy wrote: > On Mon, 08 Aug 2016, Alexander Bokovoy wrote: >> On Mon, 08 Aug 2016, Petr Vobornik wrote: >>> On 08/08/2016 12:26 PM, Alexander Bokovoy wrote: >>>> On Mon, 08 Aug 2016, Alexander Bokovoy wrote: >>>>> Hi! >>>>> >>>>> Attached patch is what is needed to allow external plugins for >>>>> FreeIPA >>>>> framework to be functional if they need to extend a schema. >>>>> >>>>> The idea is that we would have a separate directory as >>>>> /usr/share/ipa/schema.d and will allow to use schema (*.ldif) >>>>> files from >>>>> it and its subdirectories during install and upgrade stages. >>>>> >>>>> Without the patch only selected schema files from /usr/share/ipa are >>>>> used during install and upgrade. This leads to a failure to >>>>> install IPA >>>>> server (or upgrade it) if a new plugin is added. If plugin defines >>>>> managed permissions, upgrade tool will generate ACIs which will >>>>> fail to >>>>> be inserted into LDAP store due to references to missing >>>>> attributes and >>>>> object classes. >>>>> >>>>> The patch adds a directory to be installed and a helper utility that >>>>> loads files from the directory and adds them to the list of schema >>>>> files >>>>> used during update of dsinstance and upgrade of the server. >>>>> >>>>> With this patch I'm successfully managed to make FleetCommander >>>>> integration plugin completely independent of FreeIPA. >>>> Patch attached now. ;) >>>> >>> >>> I'll assume that we want to target 4.4.x therefore it can be pushed to >>> master, right? I.e. no need for creating ipa-4-4 branch atm. >> Right. >> >>> Reasoning is that currently F24 has 4.3.x. F25 will most likely have >>> 4.4.x because 4.5 is still in planning. >> Sounds good to me. FleetCommander (which is one of drivers behind the >> patches) is targeting F25 as well. > Can we get the patch reviewed? ACK However ticket is in future releases, so we have to branch master and ipa 4.4 before push Martin^2 From abokovoy at redhat.com Fri Aug 19 13:26:46 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Aug 2016 16:26:46 +0300 Subject: [Freeipa-devel] [PATCH 0214] Support schema files for external plugins In-Reply-To: References: <20160808093459.ivfpnh5femnqf7mi@redhat.com> <20160808102626.ve3ubsyhjiotpzcp@redhat.com> <20160808111248.3kpuzprcwxksfmgr@redhat.com> <20160819094345.ioyyoujpps2gkpfj@redhat.com> Message-ID: <20160819132646.3hq62lylp75jqe3p@redhat.com> On Fri, 19 Aug 2016, Martin Basti wrote: > > >On 19.08.2016 11:43, Alexander Bokovoy wrote: >>On Mon, 08 Aug 2016, Alexander Bokovoy wrote: >>>On Mon, 08 Aug 2016, Petr Vobornik wrote: >>>>On 08/08/2016 12:26 PM, Alexander Bokovoy wrote: >>>>>On Mon, 08 Aug 2016, Alexander Bokovoy wrote: >>>>>>Hi! >>>>>> >>>>>>Attached patch is what is needed to allow external plugins >>>>>>for FreeIPA >>>>>>framework to be functional if they need to extend a schema. >>>>>> >>>>>>The idea is that we would have a separate directory as >>>>>>/usr/share/ipa/schema.d and will allow to use schema >>>>>>(*.ldif) files from >>>>>>it and its subdirectories during install and upgrade stages. >>>>>> >>>>>>Without the patch only selected schema files from /usr/share/ipa are >>>>>>used during install and upgrade. This leads to a failure to >>>>>>install IPA >>>>>>server (or upgrade it) if a new plugin is added. If plugin defines >>>>>>managed permissions, upgrade tool will generate ACIs which >>>>>>will fail to >>>>>>be inserted into LDAP store due to references to missing >>>>>>attributes and >>>>>>object classes. >>>>>> >>>>>>The patch adds a directory to be installed and a helper utility that >>>>>>loads files from the directory and adds them to the list of >>>>>>schema files >>>>>>used during update of dsinstance and upgrade of the server. >>>>>> >>>>>>With this patch I'm successfully managed to make FleetCommander >>>>>>integration plugin completely independent of FreeIPA. >>>>>Patch attached now. ;) >>>>> >>>> >>>>I'll assume that we want to target 4.4.x therefore it can be pushed to >>>>master, right? I.e. no need for creating ipa-4-4 branch atm. >>>Right. >>> >>>>Reasoning is that currently F24 has 4.3.x. F25 will most likely have >>>>4.4.x because 4.5 is still in planning. >>>Sounds good to me. FleetCommander (which is one of drivers behind the >>>patches) is targeting F25 as well. >>Can we get the patch reviewed? > >ACK > >However ticket is in future releases, so we have to branch master and >ipa 4.4 before push Why? We agreed above to get the patch into 4.4. Moving ticket to 4.4.1 milestone is certainly possible and does not require branching. -- / Alexander Bokovoy From mbasti at redhat.com Fri Aug 19 13:36:31 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Aug 2016 15:36:31 +0200 Subject: [Freeipa-devel] [PATCH 0214] Support schema files for external plugins In-Reply-To: <20160819132646.3hq62lylp75jqe3p@redhat.com> References: <20160808093459.ivfpnh5femnqf7mi@redhat.com> <20160808102626.ve3ubsyhjiotpzcp@redhat.com> <20160808111248.3kpuzprcwxksfmgr@redhat.com> <20160819094345.ioyyoujpps2gkpfj@redhat.com> <20160819132646.3hq62lylp75jqe3p@redhat.com> Message-ID: <92ed4f04-842c-34a8-fd51-be89689dc59d@redhat.com> On 19.08.2016 15:26, Alexander Bokovoy wrote: > On Fri, 19 Aug 2016, Martin Basti wrote: >> >> >> On 19.08.2016 11:43, Alexander Bokovoy wrote: >>> On Mon, 08 Aug 2016, Alexander Bokovoy wrote: >>>> On Mon, 08 Aug 2016, Petr Vobornik wrote: >>>>> On 08/08/2016 12:26 PM, Alexander Bokovoy wrote: >>>>>> On Mon, 08 Aug 2016, Alexander Bokovoy wrote: >>>>>>> Hi! >>>>>>> >>>>>>> Attached patch is what is needed to allow external plugins for >>>>>>> FreeIPA >>>>>>> framework to be functional if they need to extend a schema. >>>>>>> >>>>>>> The idea is that we would have a separate directory as >>>>>>> /usr/share/ipa/schema.d and will allow to use schema (*.ldif) >>>>>>> files from >>>>>>> it and its subdirectories during install and upgrade stages. >>>>>>> >>>>>>> Without the patch only selected schema files from /usr/share/ipa >>>>>>> are >>>>>>> used during install and upgrade. This leads to a failure to >>>>>>> install IPA >>>>>>> server (or upgrade it) if a new plugin is added. If plugin defines >>>>>>> managed permissions, upgrade tool will generate ACIs which will >>>>>>> fail to >>>>>>> be inserted into LDAP store due to references to missing >>>>>>> attributes and >>>>>>> object classes. >>>>>>> >>>>>>> The patch adds a directory to be installed and a helper utility >>>>>>> that >>>>>>> loads files from the directory and adds them to the list of >>>>>>> schema files >>>>>>> used during update of dsinstance and upgrade of the server. >>>>>>> >>>>>>> With this patch I'm successfully managed to make FleetCommander >>>>>>> integration plugin completely independent of FreeIPA. >>>>>> Patch attached now. ;) >>>>>> >>>>> >>>>> I'll assume that we want to target 4.4.x therefore it can be >>>>> pushed to >>>>> master, right? I.e. no need for creating ipa-4-4 branch atm. >>>> Right. >>>> >>>>> Reasoning is that currently F24 has 4.3.x. F25 will most likely have >>>>> 4.4.x because 4.5 is still in planning. >>>> Sounds good to me. FleetCommander (which is one of drivers behind the >>>> patches) is targeting F25 as well. >>> Can we get the patch reviewed? >> >> ACK >> >> However ticket is in future releases, so we have to branch master and >> ipa 4.4 before push > Why? We agreed above to get the patch into 4.4. Moving ticket to 4.4.1 > milestone is certainly possible and does not require branching. OK, you agreed but nobody changed milestone of ticket Pushed to master: 7bec8a246d6712f749ec331f5bf066e3357c4ce7 Martin^2 From mbasti at redhat.com Fri Aug 19 14:06:14 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Aug 2016 16:06:14 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: References: <14a86320-7801-f00e-98bf-14b46f6a4d81@redhat.com> Message-ID: <886b5dd6-f705-b21c-b7dc-ae2626a2e087@redhat.com> On 19.08.2016 12:37, Pavel Vomacka wrote: > > > On 08/16/2016 08:21 AM, Stanislav Laznicka wrote: >> On 08/12/2016 06:48 PM, Petr Spacek wrote: >>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>> Hello, >>>> >>>> I updated the design of the Time-Based HBAC Policies according to the >>>> discussion we led here earlier. Please check the design page >>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The >>>> biggest >>>> changes are in the Implementation and Feature Management sections. >>>> I also >>>> added a short How to Use section. >> Thank you for the review! I will add some comments inline. >>> Nice page! >>> >>> On the high level it all makes sense. >>> >>> ad LDAP schema >>> ============== >>> 1) Why accessTime attribute is MAY in ipaTimeRule object class? >>> Does it make sense to have the object without accessTime? I do not >>> think so. >> My idea was that we allow users prepare a few time rule objects >> before filling them with the actual times. >>> Also, it could be good to add description attribute to the object >>> class and >>> incorporate it into commands (including find). >>> >> Definitely a good idea, I will work that in. >>> 2) Besides all this, I spent few minutes in dark history of IPA. The >>> accessTime attribute was introduced back in 2009 in commit >>> "55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new >>> schema for IPAv2". >>> >>> The commit does not contain any reasoning for the change but I can >>> see that >>> the attribute is already used as MAY in old object classes >>> ipaHBACRule and >>> ipaSELinuxUserMap. >>> >>> Is any of these a problem? >> I believe that the accessTime attribute was originally brought to IPA >> when there was an implementation of time policies for HBAC objects >> and it's been rotting there ever since those capabilities were >> removed. We may eventually use a new attribute for storage of the >> time strings as accessTime by definition is multi-valued which is not >> what's currently desired (although we may end up with it some day in >> the future). However, I don't think any other use of accessTime >> should be a problem as it's been obsoleted for a long time. >>> Why is it even in ipaSELinuxUserMap object class? >> I'm sorry to say I have no idea. I used it for what it originally was >> - a means for storing time strings at HBAC rules. >>> Commit >>> 55512dc938eb4a9a6655e473beab587e340af55c does not mention any reason >>> for doing so. >>> >>> I cannot see any other problem so the low-level stuff is good and >>> can be >>> implemented. >>> >>> >>> ad User interface >>> ================= >>> We need to polish the user interface so it really usable. >>> >>> At least the web interface should contain some shortcuts. E.g. when >>> I'm adding >>> a new HBAC rule, the "time" section should contain also "something" to >>> immediately add new time rule so I do not need to go to time rules >>> first and >>> then go back to HBAC page. > I'm definitely for creating a field where admin can choose a existing > time rule when creating a new HBAC. But I'm not sure about possibility > to create and define new time rule in dialog for creating new HBAC. I > think that mixing these two things together is like a possibility to > create a new user when you are creating a user group. Which is mixing > two different things together. I can imagine a button like "Create > HBAC and add a new time rule to it" which could store new HBAC rule > and immediately take admin to the page (or dialog) where admin can > create a new time rule with prefilled HBAC rule. But as you write > below it would be good to discuss it with some UX designer. I'm not UX guru, but if you add button there and show dialog window to create new timerule and then automatically assign it to the HBACrule it may work for me :) >>> >>> Similarly, dialog for rule modification should allow to easily >>> change all the >>> values, warn if time rules is shared, and also have an easy way to >>> 'disconnect' the time rule, i.e. make a copy of it and edit only the >>> new copy >>> (instead of the shared original). >>> > All of these points are really good. >>> All these are user interface things not affecting the low-level stuff. >>> >>> >>> Maybe you should sat down with some UX designer, talk about these >>> cases and >>> draw some hand-made pictures. >> I will add Pavel V. to CC, we may want to discuss this. >>> I do not believe that this will require any changes in schema so you >>> can >>> polish SSSD and framework implementation in meantime. >>> >>> On the link below is a PROTOTYPE-patched FreeIPA that covers most of >>> the CLI >>> functionality (except for the creation of iCalendar strings from >>> options) for >>> better illustration of the design. >>> >>> https://github.com/stlaz/freeipa/tree/timerules_2 >>> Honestly I did not look at the code today :-) >>> >>> Overall, I'm glad to see current proposal. After so many iteration, >>> we reached >>> something which does not have any glaring problem :-) >> It definitely felt better to be writing it with all the previous >> knowledge. Thank you! :-) > LGTM with all previous comments (Nitpick mode enabled: True) 1. It may not be clear from design that client is actually SSSD, and not IPA CLI client. Please write explicitly there that HBAC time rules are enforced by SSSD with libical in client side sections 2. Is there any design for SSSD part? If yes, it should be linked to this (probably client section) 3. timerule-mod, timerule-show should show all HBAC rules that are using it (Should be done by framework almost automatically, but explicit is better than implicit, please make note there). 4. timerule-del should prevent deletion of timerule if it is used by any HBAC rule (we can discuss this) 5. WebUI: it may be nice to have warning shown when user is editing time rule that is used by more than one HBACrule (even confirmation dialog would be nice) (Nitpick mode enable: False) 6. IMO we should add timerule-test (pick correct name) to test if given time/date value matches timerule 7. We should also extend hbac*-test with timerules (would be nice to mention in design) Martin^2 From mbasti at redhat.com Fri Aug 19 14:19:40 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Aug 2016 16:19:40 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add In-Reply-To: References: Message-ID: On 16.08.2016 17:35, Tomas Krizek wrote: > Hi, > > the attached patch fixes an error message when user provides an empty > key while adding otp token. > > https://fedorahosted.org/freeipa/ticket/6200 > > > I'm curious why we don't fix it here: OTPTokenKey('ipatokenotpkey?', cli_name='key', label=_('Key'), doc=_('Token secret (Base32; default: random)'), default_from=lambda: os.urandom(KEY_LENGTH), autofill=True, flags=('no_display', 'no_update', 'no_search'), ), If OTPTokenKey is mandratory, it should be required param (autofill should work in this case too) Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri Aug 19 16:05:27 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Aug 2016 18:05:27 +0200 Subject: [Freeipa-devel] [PATCH] 0084 cert-revoke: fix permission check bypass In-Reply-To: <20160819105510.GN3877@dhcp-40-8.bne.redhat.com> References: <20160819105510.GN3877@dhcp-40-8.bne.redhat.com> Message-ID: <9645d8f7-d982-89f0-1c54-d9ddd0448671@redhat.com> On 08/19/2016 12:55 PM, Fraser Tweedale wrote: > This patch fixes CVE-2016-5404. Versions for master, ipa-4-3 and > ipa-4-2 branches are attached. > > Thanks, > Fraser > Given that they has been already reviewed off-list, I created Fedora updates before these were pushed upstream: F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7898627d08 F24: https://bodhi.fedoraproject.org/updates/FEDORA-2016-92a3655b70 F25: https://bodhi.fedoraproject.org/updates/FEDORA-2016-f56c765d67 rawhide has also a new build -- Petr Vobornik From ftweedal at redhat.com Mon Aug 22 05:00:57 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 22 Aug 2016 15:00:57 +1000 Subject: [Freeipa-devel] [PATCH] 0091 Allow full customisability of CA subject name In-Reply-To: <20160819100933.GM3877@dhcp-40-8.bne.redhat.com> References: <20160715050448.GE10771@dhcp-40-8.bne.redhat.com> <20160715050539.GF10771@dhcp-40-8.bne.redhat.com> <83eb61a6-4e1f-d33a-1bbb-dacf8de522af@redhat.com> <20160719095445.GU10771@dhcp-40-8.bne.redhat.com> <4f7384ee-e648-2adb-3c86-26e297ede481@redhat.com> <63eec8fe-b64d-00db-f516-ccff6e8220a5@redhat.com> <20160815125425.GM23927@dhcp-40-8.bne.redhat.com> <20160819100933.GM3877@dhcp-40-8.bne.redhat.com> Message-ID: <20160822050057.GV3877@dhcp-40-8.bne.redhat.com> On Fri, Aug 19, 2016 at 08:09:33PM +1000, Fraser Tweedale wrote: > On Mon, Aug 15, 2016 at 10:54:25PM +1000, Fraser Tweedale wrote: > > On Mon, Aug 15, 2016 at 02:08:54PM +0200, Jan Cholasta wrote: > > > On 19.7.2016 12:05, Jan Cholasta wrote: > > > > On 19.7.2016 11:54, Fraser Tweedale wrote: > > > > > On Tue, Jul 19, 2016 at 09:36:17AM +0200, Jan Cholasta wrote: > > > > > > Hi, > > > > > > > > > > > > On 15.7.2016 07:05, Fraser Tweedale wrote: > > > > > > > On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: > > > > > > > > The attached patch is a work in progress for > > > > > > > > https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). > > > > > > > > > > > > > > > > I am sharing now to make the approach clear and solicit feedback. > > > > > > > > > > > > > > > > It has been tested for server install, replica install (with and > > > > > > > > without CA) and CA-replica install (all hosts running master+patch). > > > > > > > > > > > > > > > > Migration from earlier versions and server/replica/CA install on a > > > > > > > > CA-less deployment are not yet tested; these will be tested over > > > > > > > > coming days and patch will be tweaked as necessary. > > > > > > > > > > > > > > > > Commit message has a fair bit to say so I won't repeat here but let > > > > > > > > me know your questions and comments. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Fraser > > > > > > > > > > > > > > > It does help to attach the patch, of course ^_^ > > > > > > > > > > > > IMO explicit is better than implicit, so instead of introducing > > > > > > additional > > > > > > magic around --subject, I would rather add a new separate option for > > > > > > specifying the CA subject name (I think --ca-subject, for consistency > > > > > > with > > > > > > --ca-signing-algorithm). > > > > > > > > > > > The current situation - the --subject argument which specifies the > > > > > not the subject but the subject base, is confusing enough (to say > > > > > nothing of the limitations that give rise to the RFE). > > > > > > > > > > Retaining --subject for specifying the subject base and adding > > > > > --ca-subject for specifying the *actual* subject DN gets us over the > > > > > line in terms of the RFE, but does not make the installer less > > > > > confusing. This is why I made --subject accept the full subject DN, > > > > > with provisions to retain existing behaviour. > > > > > > > > > > IMO if we want to have separate arguments for subject DN and subject > > > > > base (I am not against it), let's bite the bullet and name arguments > > > > > accordingly. --subject should be used to specify full Subject DN, > > > > > --subject-base (or similar) for specifying subject base. > > > > > > > > IMHO --ca-subject is better than --subject, because it is more explicit > > > > whose subject name that is (the CA's). I agree that --subject should be > > > > deprecated and replaced with --subject-base. > > > > > > > > > > > > > > (I intentionally defer discussion of specific behaviour if one, none > > > > > or both are specified; let's resolve the question or renaming / > > > > > changing meaning of arguments first). > > > > > > > > > > > > > > > > By specifying the option you would override the default "CN=Certificate > > > > > > Authority,$SUBJECT_BASE" subject name. If --external-ca was not used, > > > > > > additional validation would be done to make sure the subject name meets > > > > > > Dogtag's expectations. Actually, it might make sense to always do the > > > > > > additional validation, to be able to print a warning that if a > > > > > > Dogtag-incompatible subject name is used, it won't be possible to > > > > > > change the > > > > > > CA cert chaining from externally signed to self-signed later. > > > > > > > > > > > > Honza > > > > > > Bump, any update on this? > > > > > I have an updated patch that fixes some issues Sebastian encountered > > in testing, but I've not yet tackled the main change requested by > > Honza (in brief: adding --ca-subject for specifying that, adding > > --subject-base for specifying that, and deprecating --subject; > > Sebastian, see discussion above and feel free to give your > > thoughts). I expect I'll get back onto this work within the next > > few days. > > > Update: I've got an updated version of patch almost ready for > review, but I'm still ironing out some wrinkles in replica > installation. > > Expect to be able to send it Monday or Tuesday for review. > Updated patch attached. I expect it will take a while to review, test and get the ACK, but in any case: IMO it should not be merged until after ipa-4-4 branch gets created. Thanks, Fraser -------------- next part -------------- From d49a6b113c45ecd0a6686a1821338f5cf91cb1f5 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 Jul 2016 12:57:11 +1000 Subject: [PATCH] Allow full customisability of IPA CA subject DN Currently only the "subject base" of the IPA CA subject DN can be customised via the installer's --subject option. The RDN "CN=Certificate Authority" is appended to form the subject DN, and this composition is widely assumed, hardcoded in many places. Some administrators need more control over the CA subject DN, especially to satisfy expectations of external CAs when the IPA CA is to be externally signed. This patch adds full customisability of the CA subject DN. In particular: - Deprecate the ambiguously named --subject option. - Add the --subject-base option for explicitly specifying the subject base. If not given, fall back to --subject, then to "O=$REALM". - Add the --ca-subject option for explictly specifying the CA subject DN. If not given, default to "CN=Certificate Authority, $SUBJECT_BASE". - If creating a self-signed CA, to meet Dogtag's expectations some normalisation may occur. Specifically: the "most specific" CN AVA encountered shall be the most specific RDN (it is moved if necessary); if the subject DN does not contain a CN AVA, then "CN=Certificate Authority" is appended. - The subject base need not be related to or contained within the CA subject DN. - During ipa-server-install print a summary of the subject base and CA subject DN that will be used, including a note if the subject DN was normalised. Fixes: https://fedorahosted.org/freeipa/ticket/2614 --- install/share/certmap.conf.template | 2 +- install/tools/ipa-ca-install | 27 ++++++++----- install/tools/man/ipa-server-install.1 | 12 +++++- ipaserver/install/ca.py | 21 +++++----- ipaserver/install/cainstance.py | 36 +++++++++-------- ipaserver/install/certs.py | 20 +++++++--- ipaserver/install/dsinstance.py | 57 +++++++++++--------------- ipaserver/install/installutils.py | 39 ++++++++++++++++-- ipaserver/install/ipa_cacert_manage.py | 9 ++++- ipaserver/install/krainstance.py | 22 +++++----- ipaserver/install/server/common.py | 46 +++++++++++++-------- ipaserver/install/server/install.py | 64 ++++++++++++++++++++++++------ ipaserver/install/server/replicainstall.py | 22 +++++++--- 13 files changed, 251 insertions(+), 126 deletions(-) diff --git a/install/share/certmap.conf.template b/install/share/certmap.conf.template index e76bf3c653a4f1d130ce8c264a28cac5dc63925c..d59b095faff804eae4cbd2ef984aa8ca3be52946 100644 --- a/install/share/certmap.conf.template +++ b/install/share/certmap.conf.template @@ -41,6 +41,6 @@ certmap default default #default:InitFn default:DNComps default:FilterComps uid -certmap ipaca CN=Certificate Authority,$SUBJECT_BASE +certmap ipaca $ISSUER_DN ipaca:CmapLdapAttr seeAlso ipaca:verifycert on diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install index 985e7413aa06900976934c329757ce45da5ff12d..a506984924fdd56b552aaf78ba5a5f0e6b10e461 100755 --- a/install/tools/ipa-ca-install +++ b/install/tools/ipa-ca-install @@ -20,6 +20,7 @@ import sys import os +import six import shutil import tempfile from ipapython import ipautil @@ -31,9 +32,10 @@ from ipaserver.install.installutils import check_creds, ReplicaConfig from ipaserver.install import bindinstance, dsinstance, ca from ipaserver.install import cainstance, custodiainstance, service from ipapython import version -from ipalib import api -from ipalib.constants import DOMAIN_LEVEL_0 +from ipalib import api, x509 +from ipalib.constants import DOMAIN_LEVEL_0, IPA_CA_CN from ipapython.dn import DN +from ipapython.certdb import get_ca_nickname from ipapython.config import IPAOptionParser from ipapython.ipa_log_manager import root_logger, standard_logging_setup from ipaplatform.paths import paths @@ -41,6 +43,10 @@ from ipaplatform.paths import paths log_file_name = paths.IPAREPLICA_CA_INSTALL_LOG REPLICA_INFO_TOP_DIR = None +if six.PY3: + unicode = str + + def parse_options(): usage = "%prog [options] REPLICA_FILE" parser = IPAOptionParser(usage=usage, version=version.VERSION) @@ -160,9 +166,12 @@ def install_replica(safe_options, options, filename): conn.connect(bind_dn=DN(('cn', 'Directory Manager')), bind_pw=dirman_password) - if config.subject_base is None: - attrs = conn.get_ipa_config() - config.subject_base = attrs.get('ipacertificatesubjectbase')[0] + # look up CA subject name (needed for DS certmap.conf) + ipa_ca_nickname = get_ca_nickname(config.realm_name) + db = certs.CertDB(config.realm_name, nssdir=paths.IPA_NSSDB_DIR) + cert = db.get_cert_from_db(ipa_ca_nickname) + options.subject_base = dsinstance.DsInstance().find_subject_base() + options.ca_subject = unicode(x509.load_certificate(cert).subject) if config.master_host_name is None: config.ca_host_name = \ @@ -175,7 +184,6 @@ def install_replica(safe_options, options, filename): options.domain_name = config.domain_name options.dm_password = config.dirman_password options.host_name = config.host_name - options.subject = config.subject_base if os.path.exists(cafile): options.ca_cert_file = cafile else: @@ -193,7 +201,8 @@ def install_replica(safe_options, options, filename): host_name=config.host_name, dm_password=config.dirman_password) CA.configure_replica(config.ca_host_name, - subject_base=config.subject_base, + subject_base=options.subject_base, + subject=options.ca_subject, ca_cert_bundle=ca_data) # Install CA DNS records if bindinstance.dns_container_exists(api.env.host, api.env.basedn, @@ -220,13 +229,13 @@ def install_master(safe_options, options): bind_pw=dm_password) config = api.Command['config_show']()['result'] - subject_base = config['ipacertificatesubjectbase'][0] + subject = api.Command.ca_show(IPA_CA_CN)['result']['ipacasubjectdn'] options.realm_name = api.env.realm options.domain_name = api.env.domain options.dm_password = dm_password options.host_name = api.env.host - options.subject = subject_base + options.ca_subject = subject ca.install_check(True, None, options) ca.install(True, None, options) diff --git a/install/tools/man/ipa-server-install.1 b/install/tools/man/ipa-server-install.1 index 55b49449e3c44aebfeefe5cb71d73e9abf07c5b2..9412eab4a345b1f25bdf91a09b4493ba3f27de34 100644 --- a/install/tools/man/ipa-server-install.1 +++ b/install/tools/man/ipa-server-install.1 @@ -129,8 +129,12 @@ Name of the Kerberos KDC SSL certificate to install \fB\-\-ca\-cert\-file\fR=\fIFILE\fR File containing the CA certificate of the CA which issued the Directory Server, Apache Server and Kerberos KDC certificates. The file is accepted in PEM and DER certificate and PKCS#7 certificate chain formats. This option may be used multiple times. Use this option if the CA certificate is not present in the certificate files. .TP -\fB\-\-subject\fR=\fISUBJECT\fR -The certificate subject base (default O=REALM.NAME) +\fB\-\-subject\-base\fR=\fIDN\fR +The certificate subject base (default: O=REALM.NAME). Used in the Subject DN +for host and service certificates issued using the default profile. +.TP +\fB\-\-ca\-subject\fR=\fIDN\fR +The CA certificate subject DN (default: CN=Certificate Authority,SUBJECT_BASE). .TP \fB\-\-ca\-signing\-algorithm\fR=\fIALGORITHM\fR Signing algorithm of the IPA CA certificate. Possible values are SHA1withRSA, SHA256withRSA, SHA512withRSA. Default value is SHA256withRSA. Use this option with --external-ca if the external CA does not support the default signing algorithm. @@ -200,6 +204,10 @@ An unattended uninstallation that will never prompt for user input .TP \fB\-P\fR \fIMASTER_PASSWORD\fR, \fB\-\-master\-password\fR=\fIMASTER_PASSWORD\fR The kerberos master password (normally autogenerated). +.TP +\fB\-\-subject\fR=\fIDN\fR +The certificate subject base (default: O=REALM.NAME). Used in the Subject DN +for host and service certificates issued using the default profile. .SH "EXIT STATUS" 0 if the (un)installation was successful diff --git a/ipaserver/install/ca.py b/ipaserver/install/ca.py index 00e0b038ca03320fd7b8268fb3eb96c5bc50a3ac..e143944d2af11dabd2e870484c7c2a1178a1f885 100644 --- a/ipaserver/install/ca.py +++ b/ipaserver/install/ca.py @@ -25,7 +25,7 @@ def install_check(standalone, replica_config, options): realm_name = options.realm_name host_name = options.host_name - subject_base = options.subject + subject_base = options.subject_base if replica_config is not None: if standalone and api.env.ra_plugin == 'selfsign': @@ -68,7 +68,7 @@ def install_check(standalone, replica_config, options): "--external-ca.") external_cert_file, external_ca_file = installutils.load_external_cert( - options.external_cert_files, options.subject) + options.external_cert_files, options.ca_subject) elif options.external_ca: if cainstance.is_step_one_done(): raise ScriptError( @@ -104,7 +104,7 @@ def install_check(standalone, replica_config, options): if not cert: continue subject = DN(str(x509.get_subject(cert))) - if subject in (DN('CN=Certificate Authority', subject_base), + if subject in (DN(options.ca_subject), DN('CN=IPA RA', subject_base), DN('CN=Object Signing Cert', subject_base)): raise ScriptError( @@ -122,7 +122,6 @@ def install_step_0(standalone, replica_config, options): domain_name = options.domain_name dm_password = options.dm_password host_name = options.host_name - subject_base = options.subject if replica_config is not None: # Configure the CA if necessary @@ -134,8 +133,10 @@ def install_step_0(standalone, replica_config, options): if standalone: api.Backend.ldap2.disconnect() - cainstance.install_replica_ca(replica_config, postinstall, - ra_p12=getattr(options, 'ra_p12', None)) + cainstance.install_replica_ca( + replica_config, postinstall, + ra_p12=getattr(options, 'ra_p12', None), + subject=options.ca_subject) if standalone and not api.Backend.ldap2.isconnected(): api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')), @@ -155,19 +156,19 @@ def install_step_0(standalone, replica_config, options): ca.create_ra_agent_db = False if external == 0: ca.configure_instance(host_name, dm_password, - dm_password, subject_base=subject_base, + dm_password, subject=options.ca_subject, ca_signing_algorithm=options.ca_signing_algorithm) elif external == 1: ca.configure_instance(host_name, dm_password, dm_password, csr_file=paths.ROOT_IPA_CSR, - subject_base=subject_base, + subject=options.ca_subject, ca_signing_algorithm=options.ca_signing_algorithm, ca_type=options.external_ca_type) else: ca.configure_instance(host_name, dm_password, dm_password, cert_file=external_cert_file.name, cert_chain_file=external_ca_file.name, - subject_base=subject_base, + subject=options.ca_subject, ca_signing_algorithm=options.ca_signing_algorithm) @@ -176,7 +177,7 @@ def install_step_1(standalone, replica_config, options): domain_name = options.domain_name dm_password = options.dm_password host_name = options.host_name - subject_base = options.subject + subject_base = options.subject_base basedn = ipautil.realm_to_suffix(realm_name) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 2ec02d6628ebc9e3a9bad141ec636c84eab14cef..94898afcd0aa9b3e2326089cafd9f2f9723202e9 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -345,7 +345,8 @@ class CAInstance(DogtagInstance): pkcs12_info=None, master_host=None, csr_file=None, cert_file=None, cert_chain_file=None, master_replication_port=None, - subject_base=None, ca_signing_algorithm=None, + subject_base=None, subject=None, + ca_signing_algorithm=None, ca_type=None, ra_p12=None): """Create a CA instance. @@ -365,10 +366,12 @@ class CAInstance(DogtagInstance): self.clone = True self.master_host = master_host self.master_replication_port = master_replication_port - if subject_base is None: - self.subject_base = DN(('O', self.realm)) - else: - self.subject_base = subject_base + + self.subject_base = \ + subject_base or installutils.default_subject_base(self.realm) + self.subject = \ + subject or installutils.default_ca_subject_dn(self.subject_base) + if ca_signing_algorithm is None: self.ca_signing_algorithm = 'SHA256withRSA' else: @@ -502,7 +505,7 @@ class CAInstance(DogtagInstance): config.set("CA", "pki_audit_signing_subject_dn", str(DN(('cn', 'CA Audit'), self.subject_base))) config.set("CA", "pki_ca_signing_subject_dn", - str(DN(('cn', 'Certificate Authority'), self.subject_base))) + str(self.subject)) # Certificate nicknames config.set("CA", "pki_subsystem_nickname", "subsystemCert cert-pki-ca") @@ -776,7 +779,7 @@ class CAInstance(DogtagInstance): userCertificate=[cert_data], description=['2;%s;%s;%s' % ( cert.serial_number, - DN(('CN', 'Certificate Authority'), self.subject_base), + DN(self.subject), DN(('CN', 'IPA RA'), self.subject_base))]) conn.add_entry(entry) @@ -855,7 +858,7 @@ class CAInstance(DogtagInstance): st = 1 en = 0 subid = 0 - ca_dn = DN(('CN','Certificate Authority'), self.subject_base) + ca_dn = DN(self.subject) while st > 0: st = certlist.find('-----BEGIN', en) en = certlist.find('-----END', en+1) @@ -1306,7 +1309,7 @@ class CAInstance(DogtagInstance): basedn = ipautil.realm_to_suffix(self.realm) self.ldap_enable('CA', self.fqdn, None, basedn) - def configure_replica(self, master_host, subject_base=None, + def configure_replica(self, master_host, subject_base=None, subject=None, ca_cert_bundle=None, ca_signing_algorithm=None, ca_type=None): """Creates a replica CA, creating a local DS backend and using @@ -1315,10 +1318,12 @@ class CAInstance(DogtagInstance): """ self.master_host = master_host self.master_replication_port = 389 - if subject_base is None: - self.subject_base = DN(('O', self.realm)) - else: - self.subject_base = subject_base + + self.subject_base = \ + subject_base or installutils.default_subject_base(self.realm) + self.subject = \ + subject or installutils.default_ca_subject_dn(self.subject_base) + if ca_signing_algorithm is None: self.ca_signing_algorithm = 'SHA256withRSA' else: @@ -1490,7 +1495,7 @@ def replica_ca_install_check(config): exit('IPA schema missing on master CA directory server') -def install_replica_ca(config, postinstall=False, ra_p12=None): +def install_replica_ca(config, postinstall=False, ra_p12=None, subject=None): """ Install a CA on a replica. @@ -1510,7 +1515,6 @@ def install_replica_ca(config, postinstall=False, ra_p12=None): ca = CAInstance(config.realm_name, certs.NSS_DIR) ca.dm_password = config.dirman_password - ca.subject_base = config.subject_base if not config.setup_ca: # We aren't configuring the CA in this step but we still need @@ -1529,7 +1533,7 @@ def install_replica_ca(config, postinstall=False, ra_p12=None): pkcs12_info=(cafile,), ra_p12=ra_p12, master_host=config.master_host_name, master_replication_port=config.ca_ds_port, - subject_base=config.subject_base) + subject=subject) # Restart httpd since we changed it's config and added ipa-pki-proxy.conf # Without the restart, CA service status check would fail due to missing diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py index 9eaec73300ebb61f2e71e72a03114c870966d95f..b154c3b9e36ea874b45225b0ba09af468c115072 100644 --- a/ipaserver/install/certs.py +++ b/ipaserver/install/certs.py @@ -72,9 +72,19 @@ class CertDB(object): This class knows IPA-specific details such as nssdir location, or the CA cert name. + + ``ca_subject_dn`` + IPA CA subject DN. This argument is required when importing + CA certificates into the certificate database. + ``subject_base`` + Realm subject base DN. This argument is required when creating + server or object signing certs. + """ # TODO: Remove all selfsign code - def __init__(self, realm, nssdir=NSS_DIR, fstore=None, host_name=None, subject_base=None): + def __init__( + self, realm, nssdir=NSS_DIR, fstore=None, host_name=None, + ca_subject_dn=None, subject_base=None): self.nssdb = NSSDatabase(nssdir) self.secdir = nssdir @@ -93,15 +103,13 @@ class CertDB(object): self.certreq_fname = None self.certder_fname = None self.host_name = host_name + self.ca_subject_dn = ca_subject_dn self.subject_base = subject_base try: self.cwd = os.getcwd() except OSError as e: raise RuntimeError("Unable to determine the current directory: %s" % str(e)) - if not subject_base: - self.subject_base = DN(('O', 'IPA')) - self.cacert_name = get_ca_nickname(self.realm) self.valid_months = "120" self.keysize = "1024" @@ -120,6 +128,7 @@ class CertDB(object): else: self.fstore = sysrestore.FileStore(paths.SYSRESTORE) + ca_subject_dn = ipautil.dn_attribute_property('_ca_subject_dn') subject_base = ipautil.dn_attribute_property('_subject_base') def __del__(self): @@ -253,13 +262,12 @@ class CertDB(object): certs = fd.read() fd.close() - ca_dn = DN(('CN','Certificate Authority'), self.subject_base) st = 0 while True: try: (cert, st) = find_cert_from_txt(certs, st) (rdn, subject_dn) = get_cert_nickname(cert) - if subject_dn == ca_dn: + if subject_dn == self.ca_subject_dn: nick = get_ca_nickname(self.realm) else: nick = str(subject_dn) diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 26cd2461a6833b7e129411b0005ba3a521bd3232..525857c3b5eef60dd1639a465fd2988646329904 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -238,6 +238,7 @@ class DsInstance(service.Service): self.dercert = None self.idstart = None self.idmax = None + self.subject = None self.subject_base = None self.open_ports = [] self.run_init_memberof = True @@ -255,6 +256,7 @@ class DsInstance(service.Service): self.fstore = sysrestore.FileStore(paths.SYSRESTORE) + subject = ipautil.dn_attribute_property('_subject') subject_base = ipautil.dn_attribute_property('_subject_base') def __common_setup(self, enable_ssl=False): @@ -303,7 +305,8 @@ class DsInstance(service.Service): self.step("configuring directory to start on boot", self.__enable) def init_info(self, realm_name, fqdn, domain_name, dm_password, - subject_base, idstart, idmax, pkcs12_info, ca_file=None): + subject_base, subject, + idstart, idmax, pkcs12_info, ca_file=None): self.realm = realm_name.upper() self.serverid = installutils.realm_to_serverid(self.realm) self.suffix = ipautil.realm_to_suffix(self.realm) @@ -312,6 +315,7 @@ class DsInstance(service.Service): self.domain = domain_name self.principal = "ldap/%s@%s" % (self.fqdn, self.realm) self.subject_base = subject_base + self.subject = subject self.idstart = idstart self.idmax = idmax self.pkcs12_info = pkcs12_info @@ -323,11 +327,13 @@ class DsInstance(service.Service): def create_instance(self, realm_name, fqdn, domain_name, dm_password, pkcs12_info=None, - idstart=1100, idmax=999999, subject_base=None, + idstart=1100, idmax=999999, + subject_base=None, subject=None, hbac_allow=True, ca_file=None): self.init_info( realm_name, fqdn, domain_name, dm_password, - subject_base, idstart, idmax, pkcs12_info, ca_file=ca_file) + subject_base, subject, + idstart, idmax, pkcs12_info, ca_file=ca_file) self.__common_setup() self.step("restarting directory server", self.__restart_instance) @@ -361,8 +367,9 @@ class DsInstance(service.Service): self.start_creation(runtime=10) def create_replica(self, realm_name, master_fqdn, fqdn, - domain_name, dm_password, subject_base, api, - pkcs12_info=None, ca_file=None, + domain_name, dm_password, + subject_base, subject, + api, pkcs12_info=None, ca_file=None, ca_is_configured=None, promote=False): # idstart and idmax are configured so that the range is seen as # depleted by the DNA plugin and the replica will go and get a @@ -377,6 +384,7 @@ class DsInstance(service.Service): domain_name=domain_name, dm_password=dm_password, subject_base=subject_base, + subject=subject, idstart=idstart, idmax=idmax, pkcs12_info=pkcs12_info, @@ -760,7 +768,9 @@ class DsInstance(service.Service): def __enable_ssl(self): dirname = config_dirname(self.serverid) - dsdb = certs.CertDB(self.realm, nssdir=dirname, subject_base=self.subject_base) + dsdb = certs.CertDB( + self.realm, nssdir=dirname, + ca_subject_dn=self.subject, subject_base=self.subject_base) if self.pkcs12_info: if self.ca_is_configured: trust_flags = 'CT,C,C' @@ -878,7 +888,7 @@ class DsInstance(service.Service): shutil.copyfile(ipautil.SHARE_DIR + "certmap.conf.template", config_dirname(self.serverid) + "certmap.conf") installutils.update_file(config_dirname(self.serverid) + "certmap.conf", - '$SUBJECT_BASE', str(self.subject_base)) + '$ISSUER_DN', str(self.subject)) sysupgrade.set_upgrade_state( 'certmap.conf', 'subject_base', @@ -1021,7 +1031,9 @@ class DsInstance(service.Service): self.stop() dirname = config_dirname(installutils.realm_to_serverid(self.realm)) - certdb = certs.CertDB(self.realm, nssdir=dirname, subject_base=self.subject_base) + certdb = certs.CertDB( + self.realm, nssdir=dirname, + ca_subject_dn=self.subject, subject_base=self.subject_base) if not cacert_name or len(cacert_name) == 0: cacert_name = "Imported CA" # we can't pass in the nickname, so we set the instance variable @@ -1144,8 +1156,7 @@ class DsInstance(service.Service): Try to find the current value of certificate subject base. 1) Look in sysupgrade first 2) If no value is found there, look in DS (start DS if necessary) - 3) Last resort, look in the certmap.conf itself - 4) If all fails, log loudly and return None + 3) If all fails, log loudly and return None Note that this method can only be executed AFTER the ipa server is configured, the api is initialized elsewhere and @@ -1193,27 +1204,6 @@ class DsInstance(service.Service): except Exception: pass - if not subject_base: - root_logger.debug('Unable to find certificate subject base in DS') - root_logger.debug('Trying to find certificate subject base in ' - 'certmap.conf') - - certmap_dir = config_dirname( - installutils.realm_to_serverid(api.env.realm) - ) - try: - with open(os.path.join(certmap_dir, 'certmap.conf')) as f: - for line in f: - if line.startswith('certmap ipaca'): - subject_base = line.strip().split(',')[-1] - root_logger.debug( - 'Found certificate subject base in certmap.conf: ' - '%s', subject_base) - - except IOError as e: - root_logger.error('Cannot open certmap.conf to find certificate ' - 'subject base: %s', e.strerror) - if subject_base: return subject_base @@ -1250,9 +1240,10 @@ class DsInstance(service.Service): os.chown(paths.DS_KEYTAB, pent.pw_uid, pent.pw_gid) def __get_ds_cert(self): - subject = DN(('O', self.realm)) nssdb_dir = config_dirname(self.serverid) - db = certs.CertDB(self.realm, nssdir=nssdb_dir, subject_base=subject) + db = certs.CertDB( + self.realm, nssdir=nssdb_dir, + ca_subject_dn=self.subject, subject_base=self.subject_base) db.request_service_cert(self.nickname, self.principal, self.fqdn) db.create_pin_file() diff --git a/ipaserver/install/installutils.py b/ipaserver/install/installutils.py index 7578bf8f5c0ed358014e39914ce37b65a778ea48..7144231faf40e5f658bc70fb5b1b417bea479a45 100644 --- a/ipaserver/install/installutils.py +++ b/ipaserver/install/installutils.py @@ -996,7 +996,7 @@ def check_entropy(): except ValueError as e: root_logger.debug("Invalid value in %s %s", paths.ENTROPY_AVAIL, e) -def load_external_cert(files, subject_base): +def load_external_cert(files, subject): """ Load and verify external CA certificate chain from multiple files. @@ -1004,7 +1004,7 @@ def load_external_cert(files, subject_base): chain formats. :param files: Names of files to import - :param subject_base: Subject name base for IPA certificates + :param subject: IPA CA subject DN :returns: Temporary file with the IPA CA certificate and temporary file with the external CA certificate chain """ @@ -1018,7 +1018,7 @@ def load_external_cert(files, subject_base): except RuntimeError as e: raise ScriptError(str(e)) - ca_subject = DN(('CN', 'Certificate Authority'), subject_base) + ca_subject = DN(subject) ca_nickname = None cache = {} for nickname, trust_flags in nssdb.list_certs(): @@ -1377,3 +1377,36 @@ def remove_ccache(ccache_path=None, run_as=None): except ipautil.CalledProcessError as e: root_logger.warning( "Failed to clear Kerberos credentials cache: {}".format(e)) + + +def default_subject_base(realm_name): + return DN(('O', realm_name)) + + +def default_ca_subject_dn(subject_base): + return DN(('CN', 'Certificate Authority'), subject_base) + + +def normalize_dogtag_ca_subject_dn(dn): + """ + Prepare a CA subject DN to be compliant with Dogtag. + + Move the most specific CN AVA encountered to be the most + specific RDN, if it is not already so. + + If no CN AVA is encountered, add 'CN=Certificate Authority' as + the most specific RDN. + + """ + cn_ava = None + l = [] + for rdn in DN(dn): + for ava in rdn: + if cn_ava is None and ava.attr.lower() == 'cn': + cn_ava = ava + else: + l.append(ava) + if cn_ava is None: + cn_ava = ('cn', 'Certificate Authority') + l.insert(0, cn_ava) + return DN(*l) diff --git a/ipaserver/install/ipa_cacert_manage.py b/ipaserver/install/ipa_cacert_manage.py index 32ef25c7aac3e57d27955b6a2608adb6a1626019..044328464bfe9ce8fea3ffb03d6fa92eb70fa822 100644 --- a/ipaserver/install/ipa_cacert_manage.py +++ b/ipaserver/install/ipa_cacert_manage.py @@ -24,6 +24,7 @@ from optparse import OptionGroup from nss import nss from nss.error import NSPRError import gssapi +import six from ipapython import admintool, certmonger, ipautil from ipapython.dn import DN @@ -31,6 +32,9 @@ from ipaplatform.paths import paths from ipalib import api, errors, x509, certstore from ipaserver.install import certs, cainstance, installutils +if six.PY3: + unicode = str + class CACertManage(admintool.AdminTool): command_name = 'ipa-cacert-manage' @@ -198,8 +202,6 @@ class CACertManage(admintool.AdminTool): options = self.options conn = api.Backend.ldap2 - cert_file, ca_file = installutils.load_external_cert( - options.external_cert_files, x509.subject_base()) nss_cert = None nss.nss_init(paths.PKI_TOMCAT_ALIAS_DIR) @@ -211,6 +213,9 @@ class CACertManage(admintool.AdminTool): pkinfo = nss_cert.subject_public_key_info.format() #pylint: enable=E1101 + cert_file, ca_file = installutils.load_external_cert( + options.external_cert_files, unicode(subject)) + nss_cert = x509.load_certificate_from_file(cert_file.name) cert = nss_cert.der_data if nss_cert.subject != subject: diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py index 590a8407d76a1c54dd2323986a8981b7c4851daa..e8de01adfb50fc01159e4a7d3fe5c88ce9465911 100644 --- a/ipaserver/install/krainstance.py +++ b/ipaserver/install/krainstance.py @@ -80,7 +80,7 @@ class KRAInstance(DogtagInstance): def configure_instance(self, realm_name, host_name, dm_password, admin_password, pkcs12_info=None, master_host=None, - subject_base=None): + subject_base=None, subject=None): """Create a KRA instance. To create a clone, pass in pkcs12_info. @@ -92,10 +92,12 @@ class KRAInstance(DogtagInstance): if self.pkcs12_info is not None: self.clone = True self.master_host = master_host - if subject_base is None: - self.subject_base = DN(('O', self.realm)) - else: - self.subject_base = subject_base + + self.subject_base = \ + subject_base or installutils.default_subject_base(realm_name) + self.subject = \ + subject or installutils.default_ca_subject_dn(self.subject_base) + self.realm = realm_name self.suffix = ipautil.realm_to_suffix(realm_name) @@ -296,7 +298,7 @@ class KRAInstance(DogtagInstance): userCertificate=[cert_data], description=['2;%s;%s;%s' % ( cert.serial_number, - DN(('CN', 'Certificate Authority'), self.subject_base), + DN(self.subject), DN(('CN', 'IPA RA'), self.subject_base))]) conn.add_entry(entry) @@ -364,10 +366,10 @@ class KRAInstance(DogtagInstance): self.fqdn = host_name self.dm_password = dm_password self.master_host = master_host - if subject_base is None: - self.subject_base = DN(('O', self.realm)) - else: - self.subject_base = subject_base + + self.subject_base = \ + subject_base or installutils.default_subject_base(self.realm) + self.suffix = ipautil.realm_to_suffix(self.realm) self.pkcs12_info = kra_cert_bundle diff --git a/ipaserver/install/server/common.py b/ipaserver/install/server/common.py index e6093d15cd1067a83ed89945c4a9c983c66ec06f..9f00728dd40083f53ceed5a4c2bb9dc01e087b78 100644 --- a/ipaserver/install/server/common.py +++ b/ipaserver/install/server/common.py @@ -19,7 +19,7 @@ from ipapython.dnsutil import check_zone_overlap if six.PY3: unicode = str -VALID_SUBJECT_ATTRS = ['st', 'o', 'ou', 'dnqualifier', 'c', +VALID_SUBJECT_ATTRS = ['cn', 'st', 'o', 'ou', 'dnqualifier', 'c', 'serialnumber', 'l', 'title', 'sn', 'givenname', 'initials', 'generationqualifier', 'dc', 'mail', 'uid', 'postaladdress', 'postalcode', 'postofficebox', @@ -28,6 +28,21 @@ VALID_SUBJECT_ATTRS = ['st', 'o', 'ou', 'dnqualifier', 'c', 'incorporationcountry', 'businesscategory'] +def _subject_validator(knob, value): + v = unicode(value, 'utf-8') + if any(ord(c) < 0x20 for c in v): + raise ValueError("must not contain control characters") + if '&' in v: + raise ValueError("must not contain an ampersand (\"&\")") + try: + dn = DN(v) + for rdn in dn: + if rdn.attr.lower() not in VALID_SUBJECT_ATTRS: + raise ValueError("invalid attribute: \"%s\"" % rdn.attr) + except ValueError as e: + raise ValueError("invalid subject base format: %s" % e) + + class BaseServerCA(common.Installable, core.Group, core.Composite): description = "certificate system" @@ -130,23 +145,22 @@ class BaseServerCA(common.Installable, core.Group, core.Composite): subject = Knob( str, None, + deprecated=True, description="The certificate subject base (default O=)", - ) + cli_metavar='DN', + ).validator(_subject_validator) - @subject.validator - def subject(self, value): - v = unicode(value, 'utf-8') - if any(ord(c) < 0x20 for c in v): - raise ValueError("must not contain control characters") - if '&' in v: - raise ValueError("must not contain an ampersand (\"&\")") - try: - dn = DN(v) - for rdn in dn: - if rdn.attr.lower() not in VALID_SUBJECT_ATTRS: - raise ValueError("invalid attribute: \"%s\"" % rdn.attr) - except ValueError as e: - raise ValueError("invalid subject base format: %s" % e) + subject_base = Knob( + str, None, + description="The certificate subject base (default O=)", + cli_metavar='DN', + ).validator(_subject_validator) + + ca_subject = Knob( + str, None, + description="The CA certificate subject DN (default CN=Certificate Authority,$SUBJECT_BASE)", + cli_metavar='DN', + ).validator(_subject_validator) ca_signing_algorithm = Knob( {'SHA1withRSA', 'SHA256withRSA', 'SHA512withRSA'}, None, diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py index 6644a6b31943f6a4826a531df5c50df9a562fdff..b54028437202f8ee78933a9b999e50a7478bd01a 100644 --- a/ipaserver/install/server/install.py +++ b/ipaserver/install/server/install.py @@ -239,7 +239,7 @@ def check_dirsrv(unattended): raise ScriptError(msg) -def set_subject_in_config(realm_name, dm_password, suffix, subject_base): +def set_subject_base_in_config(realm_name, dm_password, suffix, subject_base): ldapuri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % ( installutils.realm_to_serverid(realm_name) ) @@ -335,6 +335,13 @@ def install_check(installer): "manually.") print(textwrap.fill(msg, width=79, replace_whitespace=False)) + if options.subject: + msg = ( + "WARNING: option '--subject' is deprecated. " + "It has been superseded by '--subject-base'." + ) + print(textwrap.fill(msg, width=79, replace_whitespace=False)) + installer._installation_cleanup = True print("\nThe log file for this installation can be found in " @@ -482,8 +489,27 @@ def install_check(installer): else: realm_name = options.realm_name.upper() - if not options.subject: - options.subject = DN(('O', realm_name)) + if not options.subject_base: + if options.subject: + # deprecated option was supplied + options.subject_base = options.subject + else: + options.subject_base = \ + installutils.default_subject_base(realm_name) + + if not options.ca_subject: + options.ca_subject = \ + installutils.default_ca_subject_dn(options.subject_base) + + ca_subject_normalized = False + if not (options.external_ca or options.external_cert_files): + # CA will be self-signed by Dogtag; + # normalize DN to Dogtag's expectations + sdn_norm = installutils.normalize_dogtag_ca_subject_dn( + options.ca_subject) + if sdn_norm != options.ca_subject: + ca_subject_normalized = True + options.ca_subject = sdn_norm if options.http_cert_files: if options.http_pin is None: @@ -622,6 +648,15 @@ def install_check(installer): print("Realm name: %s" % realm_name) print() + if options.setup_ca: + print("The CA will be configured with:") + dn_msg = "CA subject DN: %s" % options.ca_subject + if ca_subject_normalized: + dn_msg += " (normalized)" + print(dn_msg) + print("Cert subject base: %s" % options.subject_base) + print() + if options.setup_dns: print("BIND DNS server will be configured to serve IPA domain with:") print("Forwarders: %s" % ( @@ -735,7 +770,8 @@ def install(installer): ds.create_instance(realm_name, host_name, domain_name, dm_password, dirsrv_pkcs12_info, idstart=options.idstart, idmax=options.idmax, - subject_base=options.subject, + subject_base=options.subject_base, + subject=options.ca_subject, hbac_allow=not options.no_hbac_allow) else: ds = dsinstance.DsInstance(fstore=fstore, @@ -745,7 +781,8 @@ def install(installer): ds.create_instance(realm_name, host_name, domain_name, dm_password, idstart=options.idstart, idmax=options.idmax, - subject_base=options.subject, + subject_base=options.subject_base, + subject=options.ca_subject, hbac_allow=not options.no_hbac_allow) ntpinstance.ntp_ldap_enable(host_name, ds.suffix, realm_name) @@ -756,7 +793,7 @@ def install(installer): installer._ds = ds ds.init_info( realm_name, host_name, domain_name, dm_password, - options.subject, 1101, 1100, None) + options.subject_base, options.ca_subject, 1101, 1100, None) if setup_ca: if not options.external_cert_files and options.external_ca: @@ -791,12 +828,12 @@ def install(installer): dm_password, master_password, setup_pkinit=not options.no_pkinit, pkcs12_info=pkinit_pkcs12_info, - subject_base=options.subject) + subject_base=options.subject_base) else: krb.create_instance(realm_name, host_name, domain_name, dm_password, master_password, setup_pkinit=not options.no_pkinit, - subject_base=options.subject) + subject_base=options.subject_base) if setup_ca: ca.install_step_1(False, None, options) @@ -821,13 +858,13 @@ def install(installer): if options.http_cert_files: http.create_instance( realm_name, host_name, domain_name, dm_password, - pkcs12_info=http_pkcs12_info, subject_base=options.subject, + pkcs12_info=http_pkcs12_info, subject_base=options.subject_base, auto_redirect=not options.no_ui_redirect, ca_is_configured=setup_ca) else: http.create_instance( realm_name, host_name, domain_name, dm_password, - subject_base=options.subject, + subject_base=options.subject_base, auto_redirect=not options.no_ui_redirect, ca_is_configured=setup_ca) tasks.restore_context(paths.CACHE_IPA_SESSIONS) @@ -837,8 +874,9 @@ def install(installer): os.chmod(CACERT, 0o644) ca_db.publish_ca_cert(CACERT) - set_subject_in_config(realm_name, dm_password, - ipautil.realm_to_suffix(realm_name), options.subject) + set_subject_base_in_config( + realm_name, dm_password, + ipautil.realm_to_suffix(realm_name), options.subject_base) # Apply any LDAP updates. Needs to be done after the configuration file # is created @@ -1190,6 +1228,8 @@ class ServerCA(BaseServerCA): pkinit_cert_name = Knob(BaseServerCA.pkinit_cert_name) ca_cert_files = Knob(BaseServerCA.ca_cert_files) subject = Knob(BaseServerCA.subject) + subject_base = Knob(BaseServerCA.subject_base) + ca_subject = Knob(BaseServerCA.ca_subject) ca_signing_algorithm = Knob(BaseServerCA.ca_signing_algorithm) skip_schema_check = None diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py index c73600ccad4ededd6f5b17dd5a35479af9093166..fa2ef1808ca95618464f3108bce9738ce6d899fd 100644 --- a/ipaserver/install/server/replicainstall.py +++ b/ipaserver/install/server/replicainstall.py @@ -18,6 +18,7 @@ import tempfile import six from ipapython import ipaldap, ipautil, sysrestore +from ipapython.certdb import get_ca_nickname from ipapython.dn import DN from ipapython.install.common import step from ipapython.install.core import Knob @@ -71,7 +72,7 @@ def make_pkcs12_info(directory, cert_name, password_name): return None -def install_http_certs(config, fstore, remote_api): +def install_http_certs(config, fstore, remote_api, subject_base): # Obtain keytab for the HTTP service fstore.backup_file(paths.IPA_KEYTAB) @@ -89,8 +90,7 @@ def install_http_certs(config, fstore, remote_api): # Obtain certificate for the HTTP service nssdir = certs.NSS_DIR - subject = DN(('O', config.realm_name)) - db = certs.CertDB(config.realm_name, nssdir=nssdir, subject_base=subject) + db = certs.CertDB(config.realm_name, nssdir=nssdir, subject_base=subject_base) db.request_service_cert('Server-Cert', principal, config.host_name, True) # FIXME: need Signing-Cert too ? @@ -120,6 +120,7 @@ def install_replica_ds(config, options, ca_is_configured, remote_api, domain_name=config.domain_name, dm_password=config.dirman_password, subject_base=config.subject_base, + subject=options.ca_subject, pkcs12_info=pkcs12_info, ca_is_configured=ca_is_configured, ca_file=ca_file, @@ -599,6 +600,9 @@ def install_check(installer): raise RuntimeError("CA cert file is not available. Please run " "ipa-replica-prepare to create a new replica file.") + # look up CA subject name (needed for DS certmap.conf) + options.ca_subject = unicode(x509.load_certificate_from_file(cafile).subject) + for pkcs12_name, pin_name in (('dscert.p12', 'dirsrv_pin.txt'), ('httpcert.p12', 'http_pin.txt')): pkcs12_info = make_pkcs12_info(config.dir, pkcs12_name, pin_name) @@ -717,7 +721,6 @@ def install_check(installer): if options.setup_ca: options.realm_name = config.realm_name options.host_name = config.host_name - options.subject = config.subject_base ca.install_check(False, config, options) if config.setup_kra: @@ -1256,6 +1259,12 @@ def promote_check(installer): if subject_base is not None: config.subject_base = DN(subject_base) + # look up CA subject name (needed for DS certmap.conf) + ipa_ca_nickname = get_ca_nickname(config.realm_name) + db = certs.CertDB(config.realm_name, nssdir=paths.IPA_NSSDB_DIR) + cert = db.get_cert_from_db(ipa_ca_nickname) + options.ca_subject = unicode(x509.load_certificate(cert).subject) + # Find if any server has a CA ca_host = service.find_providing_server('CA', conn, api.env.server) if ca_host is not None: @@ -1289,7 +1298,7 @@ def promote_check(installer): options.realm_name = config.realm_name options.host_name = config.host_name - options.subject = config.subject_base + ca.install_check(False, None, options) if config.setup_kra: @@ -1418,7 +1427,7 @@ def promote(installer): # Must install http certs before changing ipa configuration file # or certmonger will fail to contact the peer master - install_http_certs(config, fstore, remote_api) + install_http_certs(config, fstore, remote_api, config.subject_base) ntpinstance.ntp_ldap_enable(config.host_name, ds.suffix, remote_api.env.realm) @@ -1507,6 +1516,7 @@ def promote(installer): dm_password=config.dirman_password) ca.configure_replica(config.ca_host_name, subject_base=config.subject_base, + subject=options.ca_subject, ca_cert_bundle=ca_data) if options.setup_kra: -- 2.5.5 From jcholast at redhat.com Mon Aug 22 05:21:17 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Aug 2016 07:21:17 +0200 Subject: [Freeipa-devel] [PATCH] 0084 cert-revoke: fix permission check bypass In-Reply-To: <20160819105510.GN3877@dhcp-40-8.bne.redhat.com> References: <20160819105510.GN3877@dhcp-40-8.bne.redhat.com> Message-ID: <891fa947-3003-5402-6bb8-29a6523d486e@redhat.com> Hi, On 19.8.2016 12:55, Fraser Tweedale wrote: > This patch fixes CVE-2016-5404. Versions for master, ipa-4-3 and > ipa-4-2 branches are attached. ACKed off-list. Pushed to: master: cf74584d0f772f3f5eccc1d30c001e4212a104fd ipa-4-2: e26ec4c220b10a20fa7527ad7173c89c3032e480 ipa-4-3: 7eb1502863408d869dc2e706a5e194ad122997bf > > Thanks, > Fraser -- Jan Cholasta From freeipa-github-notification at redhat.com Mon Aug 22 05:33:31 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 07:33:31 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #3] User add fix #6199 (comment) In-Reply-To: References: Message-ID: jcholast commented on a pull request This is not very comprehensible. I would rather replace the: ```python dn = self.obj.get_either_dn(*keys, **options) ``` at the beginning of `user_add.pre_callback` with: ```python delete_dn = self.obj.get_delete_dn(*keys, **options) try: ldap.get_entry(delete_dn, ['']) except errors.NotFound: pass else: self.obj.handle_duplicate_entry(*keys) ``` Note that this assumes that the routine to get `delete_dn` was split off from `user.get_either_dn()` into `user.get_delete_dn()` to avoid copy-pasta. See the full comment at https://github.com/freeipa/freeipa/pull/3#issuecomment-241318444 From jcholast at redhat.com Mon Aug 22 05:48:30 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Aug 2016 07:48:30 +0200 Subject: [Freeipa-devel] [PATCH 689] tests: fix test_ipalib.test_frontend.test_Object In-Reply-To: <3f502fcd-6b1a-4de0-4292-2561f707aa4a@redhat.com> References: <1fe5fa22-8162-e8cb-b5a9-14373488c19f@redhat.com> <9d8daae0-cf0e-cd5a-4868-1afb7052ebc9@redhat.com> <3f502fcd-6b1a-4de0-4292-2561f707aa4a@redhat.com> Message-ID: On 18.8.2016 11:01, Martin Basti wrote: > > > On 18.08.2016 10:56, Petr Spacek wrote: >> On 18.8.2016 10:08, Jan Cholasta wrote: >>> SSIA >> Could you add one sentence or a link to a ticket which forced this >> change? >> >> When reading the patch, I have no way to say why the change is >> necessary - so >> it is impossible to verify correctness. (Sure, the test will pass, but >> I have >> no way to distinguish incorrect test passing on incorrect >> implementation vs. >> correct test passing on correct implementation.) >> > +1 > > and add there this link also https://fedorahosted.org/freeipa/ticket/6188 Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-689.1-tests-fix-test_ipalib.test_frontend.test_Object.patch Type: text/x-patch Size: 2011 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Aug 22 06:35:48 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 08:35:48 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #4] Fix man page ipa-replica-manage: remove duplicate -c option from --no-lookup (opened) In-Reply-To: References: Message-ID: pspacek's pull request #4: "Fix man page ipa-replica-manage: remove duplicate -c option from --no-lookup" was opened PR body: https://fedorahosted.org/freeipa/ticket/6233 See the full pull-request at https://github.com/freeipa/freeipa/pull/4 From freeipa-github-notification at redhat.com Mon Aug 22 06:49:40 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 08:49:40 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #5] migrate-ds: Mention --enable-migration in error message about migraion mode (opened) In-Reply-To: References: Message-ID: pspacek's pull request #5: "migrate-ds: Mention --enable-migration in error message about migraion mode" was opened PR body: https://fedorahosted.org/freeipa/ticket/6234 See the full pull-request at https://github.com/freeipa/freeipa/pull/5 From jcholast at redhat.com Mon Aug 22 07:22:08 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Aug 2016 09:22:08 +0200 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: <20160819111122.GP3877@dhcp-40-8.bne.redhat.com> References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> <20160815071516.GL23927@dhcp-40-8.bne.redhat.com> <20160819111122.GP3877@dhcp-40-8.bne.redhat.com> Message-ID: On 19.8.2016 13:11, Fraser Tweedale wrote: > Bump for review. > > On Mon, Aug 15, 2016 at 05:15:16PM +1000, Fraser Tweedale wrote: >> Thanks for reviews. Rebased and updated patches attached (and one >> new patch). No substantive changes to 92..94. Patch order is: >> >> 92-2, 93-2, 94-2, 98, 90-3 >> >> Other comments inline. >> >> Thanks, >> Fraser >> >> On Fri, Aug 12, 2016 at 11:33:28AM +0200, Jan Cholasta wrote: >>> Patch 0092: ACK >>> >>> Patch 0093: ACK >>> >>> Patch 0094: ACK Please fix this PEP8 issue before pushing: ./ipaserver/plugins/cert.py:597:17: W503 line break before binary operator Patch 0098: ACK >>> >>> Patch 0090: >>> >>> 1) Generic otherNames (san_other) do not work correctly. The OID is not >>> included in the value and names with complex type other than >>> KerberosPrincipal are not parsed correctly. The value should include the OID >>> and DER blob of the name. >>> >> Updated to use "OID:b64(DER)" as the attribute value. OK. >> >>> 2) With --all, san_other should be included in the result for all >>> otherNames, even the known ones, to provide (limited) forward compatibility. >>> >> Done; when --all given, known otherName kinds are included in >> 'san_other' attribute in addition to their own attribute. OK. >> >>> 3) Do we have to support *all* the name types? I mean we could, for the sake >>> of completeness, but it might be easier to just keep the few ones we >>> actually care about (email, DNS name, principal name, UPN and directory name >>> in your patch 0095). >>> >> Yeah, why not support them all? See also Petr's comments in other >> branch of thread. Works for me, but see Luk??'s reply, I think he has a point. Maybe we can make a compromise and show only supported name types by default and everything with --all? >> >>> 4) >>> >>> + obj.setdefault(attr_name, []).append(unicode(name)) >>> >>> The value should not (always) be unicode, but of the type declared by the >>> param (unicode or ipapython.kerberos.Principal or >>> ipapython.dnsutil.DNSName). >>> >> I now pass the value to the constructor of whatever type the >> parameter uses: >> >> attr_value = self.params[attr_name].type(name_formatted) >> obj.setdefault(attr_name, []).append(attr_value) OK. 5) san_directoryname should be a DNParam rather than Str. 6) Could we use "Subject " instead of "Subject Alternative Name ()" for labels? Or something else which is shorter and has the name type more "visible" than the current form. 7) The patch needs a rebase. -- Jan Cholasta From freeipa-github-notification at redhat.com Mon Aug 22 07:20:25 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 09:20:25 +0200 Subject: [Freeipa-devel] [freeipa/freeipa #6] adtrust-install: Mention AD GC port 3286 in list of required ports (opened) In-Reply-To: References: Message-ID: pspacek's pull request #6: "adtrust-install: Mention AD GC port 3286 in list of required ports" was opened PR body: Port name "msft-gc" is taken form /etc/services file provided by package setup-2.10.1-1.fc24.noarch. https://fedorahosted.org/freeipa/ticket/6235 See the full pull-request at https://github.com/freeipa/freeipa/pull/6 From ftweedal at redhat.com Mon Aug 22 07:37:57 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 22 Aug 2016 17:37:57 +1000 Subject: [Freeipa-devel] invoking ipa-certupdate from within installer Message-ID: <20160822073757.GW3877@dhcp-40-8.bne.redhat.com> #6019 requires adding tracking requests for existing lightweight CAs as part of replica installation. ipa-certupdate has logic to do this. Before I go ahead and implement, there are a few approaches I want to mention and seek feedback from team members before I commit to one. 1. invoke ipa-certupdate as a subprocess, from CAInstance.configure_replica. This is the simplest approach. Not much else to say about it, really :) 2. invoke ipa-certupdate's main() from the installer. This is slightly more work because currently it would fail due to API already having been initialised. 3. extract all logic for adding tracking requests such that it can be invoked separately; then refactor ipa-certupdate to call it as well as calling it from CAInstance.configure_replica. This is the most work. I lean towards (1) or (3). If you wish it to be done a certain way say your piece. Thanks, Fraser From freeipa-github-notification at redhat.com Mon Aug 22 07:48:34 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 09:48:34 +0200 Subject: [Freeipa-devel] [freeipa PR#6] adtrust-install: Mention AD GC port 3286 in list of required ports (comment) In-Reply-To: References: Message-ID: abbra commented on a pull request Sounds good to me. Thanks. See the full comment at https://github.com/freeipa/freeipa/pull/6#issuecomment-241337413 From freeipa-github-notification at redhat.com Mon Aug 22 07:48:54 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 09:48:54 +0200 Subject: [Freeipa-devel] [freeipa PR#6] adtrust-install: Mention AD GC port 3286 in list of required ports (label change) In-Reply-To: References: Message-ID: pspacek's pull request #6: "adtrust-install: Mention AD GC port 3286 in list of required ports" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/6 From jcholast at redhat.com Mon Aug 22 08:00:57 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Aug 2016 10:00:57 +0200 Subject: [Freeipa-devel] invoking ipa-certupdate from within installer In-Reply-To: <20160822073757.GW3877@dhcp-40-8.bne.redhat.com> References: <20160822073757.GW3877@dhcp-40-8.bne.redhat.com> Message-ID: <4276987b-e546-455f-b977-bd1341703229@redhat.com> Hi, On 22.8.2016 09:37, Fraser Tweedale wrote: > #6019 requires adding tracking requests for existing lightweight CAs > as part of replica installation. ipa-certupdate has logic to do > this. > > Before I go ahead and implement, there are a few approaches I want > to mention and seek feedback from team members before I commit to > one. > > 1. invoke ipa-certupdate as a subprocess, from > CAInstance.configure_replica. This is the simplest approach. Not > much else to say about it, really :) > > 2. invoke ipa-certupdate's main() from the installer. This is > slightly more work because currently it would fail due to API > already having been initialised. > > 3. extract all logic for adding tracking requests such that it can > be invoked separately; then refactor ipa-certupdate to call it as > well as calling it from CAInstance.configure_replica. This is the > most work. > > I lean towards (1) or (3). If you wish it to be done a certain way > say your piece. (4) Extract the relevant code from ipa-certupdate into a separate function and call it from CAInstance.configure_replica(). I would not go with (1) or (2) because it does more than track the certs. I would also not go with (3) because it requires extensive changes not suitable for 4.4. > > Thanks, > Fraser > Honza -- Jan Cholasta From freeipa-github-notification at redhat.com Mon Aug 22 08:16:27 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 10:16:27 +0200 Subject: [Freeipa-devel] [freeipa PR#7] config-mod: normalize attribute names for --usersearch/--groupsearch (opened) In-Reply-To: References: Message-ID: pspacek's pull request #7: "config-mod: normalize attribute names for --usersearch/--groupsearch" was opened PR body: https://fedorahosted.org/freeipa/ticket/6236 See the full pull-request at https://github.com/freeipa/freeipa/pull/7 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-7.patch URL: From freeipa-github-notification at redhat.com Mon Aug 22 08:18:39 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 10:18:39 +0200 Subject: [Freeipa-devel] [freeipa PR#5] migrate-ds: Mention --enable-migration in error message about migraion mode (label change) In-Reply-To: References: Message-ID: pspacek's pull request #5: "migrate-ds: Mention --enable-migration in error message about migraion mode" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/5 From freeipa-github-notification at redhat.com Mon Aug 22 08:18:41 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 10:18:41 +0200 Subject: [Freeipa-devel] [freeipa PR#5] migrate-ds: Mention --enable-migration in error message about migraion mode (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request Works for me See the full comment at https://github.com/freeipa/freeipa/pull/5#issuecomment-241343377 From tkrizek at redhat.com Mon Aug 22 08:22:36 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Mon, 22 Aug 2016 10:22:36 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add In-Reply-To: References: Message-ID: Seems like a good idea, I'm attaching the updated patch. Autofill does work when the param is required. On 08/19/2016 04:19 PM, Martin Basti wrote: > > > > On 16.08.2016 17:35, Tomas Krizek wrote: >> Hi, >> >> the attached patch fixes an error message when user provides an empty >> key while adding otp token. >> >> https://fedorahosted.org/freeipa/ticket/6200 >> >> >> > > I'm curious why we don't fix it here: > > OTPTokenKey('ipatokenotpkey?', > cli_name='key', > label=_('Key'), > doc=_('Token secret (Base32; default: random)'), > default_from=lambda: os.urandom(KEY_LENGTH), > autofill=True, > flags=('no_display', 'no_update', 'no_search'), > ), > > > If OTPTokenKey is mandratory, it should be required param (autofill > should work in this case too) > > Martin^2 -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tkrizek-0003-2-Validate-key-in-otptoken-add.patch Type: text/x-patch Size: 1038 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Aug 22 08:27:31 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 10:27:31 +0200 Subject: [Freeipa-devel] [freeipa PR#7] config-mod: normalize attribute names for --usersearch/--groupsearch (label change) In-Reply-To: References: Message-ID: pspacek's pull request #7: "config-mod: normalize attribute names for --usersearch/--groupsearch" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/7 From freeipa-github-notification at redhat.com Mon Aug 22 08:27:39 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 10:27:39 +0200 Subject: [Freeipa-devel] [freeipa PR#7] config-mod: normalize attribute names for --usersearch/--groupsearch (comment) In-Reply-To: References: Message-ID: abbra commented on a pull request Looks good to me. Thanks. See the full comment at https://github.com/freeipa/freeipa/pull/7#issuecomment-241345286 From slaznick at redhat.com Mon Aug 22 08:35:50 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Mon, 22 Aug 2016 10:35:50 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <886b5dd6-f705-b21c-b7dc-ae2626a2e087@redhat.com> References: <14a86320-7801-f00e-98bf-14b46f6a4d81@redhat.com> <886b5dd6-f705-b21c-b7dc-ae2626a2e087@redhat.com> Message-ID: On 08/19/2016 04:06 PM, Martin Basti wrote: > On 19.08.2016 12:37, Pavel Vomacka wrote: >> On 08/16/2016 08:21 AM, Stanislav Laznicka wrote: >>> On 08/12/2016 06:48 PM, Petr Spacek wrote: >>>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>>> Hello, >>>>> >>>>> I updated the design of the Time-Based HBAC Policies according to the >>>>> discussion we led here earlier. Please check the design page >>>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The >>>>> biggest >>>>> changes are in the Implementation and Feature Management sections. >>>>> I also >>>>> added a short How to Use section. >>> Thank you for the review! I will add some comments inline. >>>> Nice page! >>>> >>>> On the high level it all makes sense. >>>> >>>> ad LDAP schema >>>> ============== >>>> 1) Why accessTime attribute is MAY in ipaTimeRule object class? >>>> Does it make sense to have the object without accessTime? I do not >>>> think so. >>> My idea was that we allow users prepare a few time rule objects >>> before filling them with the actual times. >>>> Also, it could be good to add description attribute to the object >>>> class and >>>> incorporate it into commands (including find). >>>> >>> Definitely a good idea, I will work that in. >>>> 2) Besides all this, I spent few minutes in dark history of IPA. The >>>> accessTime attribute was introduced back in 2009 in commit >>>> "55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new >>>> schema for IPAv2". >>>> >>>> The commit does not contain any reasoning for the change but I can >>>> see that >>>> the attribute is already used as MAY in old object classes >>>> ipaHBACRule and >>>> ipaSELinuxUserMap. >>>> >>>> Is any of these a problem? >>> I believe that the accessTime attribute was originally brought to >>> IPA when there was an implementation of time policies for HBAC >>> objects and it's been rotting there ever since those capabilities >>> were removed. We may eventually use a new attribute for storage of >>> the time strings as accessTime by definition is multi-valued which >>> is not what's currently desired (although we may end up with it some >>> day in the future). However, I don't think any other use of >>> accessTime should be a problem as it's been obsoleted for a long time. >>>> Why is it even in ipaSELinuxUserMap object class? >>> I'm sorry to say I have no idea. I used it for what it originally >>> was - a means for storing time strings at HBAC rules. >>>> Commit >>>> 55512dc938eb4a9a6655e473beab587e340af55c does not mention any >>>> reason for doing so. >>>> >>>> I cannot see any other problem so the low-level stuff is good and >>>> can be >>>> implemented. >>>> >>>> >>>> ad User interface >>>> ================= >>>> We need to polish the user interface so it really usable. >>>> >>>> At least the web interface should contain some shortcuts. E.g. when >>>> I'm adding >>>> a new HBAC rule, the "time" section should contain also "something" to >>>> immediately add new time rule so I do not need to go to time rules >>>> first and >>>> then go back to HBAC page. >> I'm definitely for creating a field where admin can choose a existing >> time rule when creating a new HBAC. But I'm not sure about >> possibility to create and define new time rule in dialog for creating >> new HBAC. I think that mixing these two things together is like a >> possibility to create a new user when you are creating a user group. >> Which is mixing two different things together. I can imagine a button >> like "Create HBAC and add a new time rule to it" which could store >> new HBAC rule and immediately take admin to the page (or dialog) >> where admin can create a new time rule with prefilled HBAC rule. But >> as you write below it would be good to discuss it with some UX designer. > > I'm not UX guru, but if you add button there and show dialog window to > create new timerule and then automatically assign it to the HBACrule > it may work for me :) > >>>> >>>> Similarly, dialog for rule modification should allow to easily >>>> change all the >>>> values, warn if time rules is shared, and also have an easy way to >>>> 'disconnect' the time rule, i.e. make a copy of it and edit only >>>> the new copy >>>> (instead of the shared original). >>>> >> All of these points are really good. > >>>> All these are user interface things not affecting the low-level stuff. >>>> >>>> >>>> Maybe you should sat down with some UX designer, talk about these >>>> cases and >>>> draw some hand-made pictures. >>> I will add Pavel V. to CC, we may want to discuss this. >>>> I do not believe that this will require any changes in schema so >>>> you can >>>> polish SSSD and framework implementation in meantime. >>>> >>>> On the link below is a PROTOTYPE-patched FreeIPA that covers most >>>> of the CLI >>>> functionality (except for the creation of iCalendar strings from >>>> options) for >>>> better illustration of the design. >>>> >>>> https://github.com/stlaz/freeipa/tree/timerules_2 >>>> Honestly I did not look at the code today :-) >>>> >>>> Overall, I'm glad to see current proposal. After so many iteration, >>>> we reached >>>> something which does not have any glaring problem :-) >>> It definitely felt better to be writing it with all the previous >>> knowledge. Thank you! :-) >> > > LGTM with all previous comments Thank you for the review, my comments are inline > > > (Nitpick mode enabled: True) > 1. > It may not be clear from design that client is actually SSSD, and not > IPA CLI client. Please write explicitly there that HBAC time rules are > enforced by SSSD with libical in client side sections Did not realize that, I will add the information. > > 2. > Is there any design for SSSD part? If yes, it should be linked to this > (probably client section) There's currently no design for the SSSD part. I think the implementation there might be straight forward enough - add caching of the new LDAP subtree, get the time rules from it, evaluate them at the given HBAC rules. > > 3. > timerule-mod, timerule-show should show all HBAC rules that are using > it (Should be done by framework almost automatically, but explicit is > better than implicit, please make note there). > I believe framework should be already doing that but I'll check. > 4. > timerule-del should prevent deletion of timerule if it is used by any > HBAC rule (we can discuss this) Perhaps just a prompt with warning showing all affected HBAC rules could do (could it?), although I am not sure if that is kosher within the framework. > > 5. > WebUI: it may be nice to have warning shown when user is editing time > rule that is used by more than one HBACrule (even confirmation dialog > would be nice) > Should something like that be also in the CLI (similarly to previous point)? > (Nitpick mode enable: False) > 6. > IMO we should add timerule-test (pick correct name) to test if given > time/date value matches timerule That seems like a reasonable idea. > > 7. > We should also extend hbac*-test with timerules (would be nice to > mention in design) Definitely, I will add that to the design, I completely forgot about hbac*-test there. From ldoudova at redhat.com Mon Aug 22 10:17:23 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 22 Aug 2016 12:17:23 +0200 Subject: [Freeipa-devel] [PATCH 0036, 0037][Tests] Host/service tests do not recognize newly added attribute Message-ID: Hi, attached patches fix test fails occuring since patch for [1] was pushed. Ticket for tests: https://fedorahosted.org/freeipa/ticket/6240 Lenka [1] https://fedorahosted.org/freeipa/ticket/5764 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0036-Tests-Host-tracker-does-not-recognize-ipakrboktoauth.patch Type: text/x-patch Size: 1665 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0037-Tests-Service-tracker-and-tests-don-t-recognize-ipak.patch Type: text/x-patch Size: 2734 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Aug 22 10:30:41 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 12:30:41 +0200 Subject: [Freeipa-devel] [freeipa PR#6] adtrust-install: Mention AD GC port 3286 in list of required ports (label change) In-Reply-To: References: Message-ID: pspacek's pull request #6: "adtrust-install: Mention AD GC port 3286 in list of required ports" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/6 From freeipa-github-notification at redhat.com Mon Aug 22 10:30:43 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 12:30:43 +0200 Subject: [Freeipa-devel] [freeipa PR#6] adtrust-install: Mention AD GC port 3286 in list of required ports (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request Fixed upstream master: https://fedorahosted.org/freeipa/changeset/3cf80e747d0172f7a80f5393c4481392e4448ca6 See the full comment at https://github.com/freeipa/freeipa/pull/6#issuecomment-241373805 From freeipa-github-notification at redhat.com Mon Aug 22 10:30:45 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 12:30:45 +0200 Subject: [Freeipa-devel] [freeipa PR#6] adtrust-install: Mention AD GC port 3286 in list of required ports (closed) In-Reply-To: References: Message-ID: pspacek's pull request #6: "adtrust-install: Mention AD GC port 3286 in list of required ports" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/6 From Peter.Marx at knorr-bremse.com Mon Aug 22 10:55:19 2016 From: Peter.Marx at knorr-bremse.com (Marx, Peter) Date: Mon, 22 Aug 2016 10:55:19 +0000 Subject: [Freeipa-devel] certmonger "failed to verify signature on server response" after receiving valid certificate Message-ID: <2C720BBFE8885346B9A4377911BABE78868950A1@MUCS72046.corp.knorr-bremse.com> I'm testing with certmonger 0.78.6 (patched for the GETCACertChain bug) against two EJBCA servers. For verification I a use a second SCEP client called jSCEP. I started certmonger in debug mode with "/usr/libexec/certmonger/certmonger-session -n -d 15" The CA file in /root/.config/certmonger/cas looks like this: id=Test_Sweden ca_aka=SCEP (certmonger 0.78.6) ca_is_default=0 ca_type=EXTERNAL ca_external_helper=/usr/libexec/certmonger/scep-submit -u http://ejbca-test2.primekey.se:8080/ejbca/publicweb/apply/scep/mxratest/pkiclient.exe -i "mx_kd3" ca_capabilities=POSTPKIOperation,Renewal,SHA-1 scep_ca_identifier=iCOM Kunde1 Schweden ca_encryption_cert=-----BEGIN CERTIFICATE----- -----END CERTIFICATE----- ca_encryption_issuer_cert=-----BEGIN CERTIFICATE----- -----END CERTIFICATE----- Issuing the request "getcert request -c Test_Sweden -v -d /tmp/nssdb -g 2048 -I husky201 -p /tmp/pwd.txt -n husky201 -L abcd -N CN='husky201' -s" gives this log: 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for 0x7fbe6b0c02e0. 2016-08-22 10:31:13 [22931] message 0x7fbe6b0c02e0(method_call)->org.fedorahosted.certmonger:/org/fedorahosted/certmonger:org.fedorahosted.certmonger.add_request 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixUser serial 135 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixProcessID serial 136 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for 0x7fbe6b0c02e0:0x7fbe6b0aa690. 2016-08-22 10:31:13 [22931] Dequeuing FD 8 for Read for 0x7fbe6b0c02e0:0x7fbe6b0aa690. 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for 0x7fbe6b0c02e0. 2016-08-22 10:31:13 [22931] message 0x7fbe6b0c02e0(method_return)->135->73 2016-08-22 10:31:13 [22931] message 0x7fbe6b0c02e0(method_return)->136->74 2016-08-22 10:31:13 [22931] User ID 0 PID 23133 called /org/fedorahosted/certmonger:org.fedorahosted.certmonger.add_request. 2016-08-22 10:31:13 [23135] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:31:13 [23135] Not attempting to set NSS FIPS mode. 2016-08-22 10:31:13 [23135] Skipping NSS internal slot (NSS Generic Crypto Services). 2016-08-22 10:31:13 [23135] Found token 'NSS Certificate DB'. 2016-08-22 10:31:13 [23135] Located the key 'husky201'. 2016-08-22 10:31:13 [23135] Converted private key 'husky201' to public key. 2016-08-22 10:31:13 [23135] Key is an RSA key. 2016-08-22 10:31:13 [23135] Key size is 2048. 2016-08-22 10:31:13 [23136] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:31:13 [23136] Not attempting to set NSS FIPS mode. 2016-08-22 10:31:13 [23136] Found token 'NSS Generic Crypto Services'. 2016-08-22 10:31:13 [23136] Cert storage slot still needs user PIN to be set. 2016-08-22 10:31:13 [23136] Found token 'NSS Certificate DB'. 2016-08-22 10:31:13 [23136] Error locating certificate. 2016-08-22 10:31:13 [22931] Request7('husky201') starts in state 'NEWLY_ADDED' 2016-08-22 10:31:13 [22931] Request7('husky201') taking writing lock 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'NEWLY_ADDED_START_READING_KEYINFO' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. 2016-08-22 10:31:13 [22931] Started Request7('husky201'). 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for 0x7fbe6b0c02e0:0x7fbe6b09b4e0. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'NEWLY_ADDED_READING_KEYINFO' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic from 11. 2016-08-22 10:31:13 [22931] Dequeuing FD 8 for Read for 0x7fbe6b0c02e0:0x7fbe6b09b4e0. 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for 0x7fbe6b0c02e0. 2016-08-22 10:31:13 [22931] message 0x7fbe6b0c02e0(method_call)->org.fedorahosted.certmonger:/org/fedorahosted/certmonger/requests/Request7:org.fedorahosted.certmonger.request.get_nickname 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixUser serial 140 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixProcessID serial 141 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for 0x7fbe6b0c02e0:0x7fbe6b0ae0a0. 2016-08-22 10:31:13 [22931] Dequeuing FD 8 for Read for 0x7fbe6b0c02e0:0x7fbe6b0ae0a0. 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for 0x7fbe6b0c02e0. 2016-08-22 10:31:13 [22931] message 0x7fbe6b0c02e0(method_return)->140->75 2016-08-22 10:31:13 [22931] message 0x7fbe6b0c02e0(method_return)->141->76 2016-08-22 10:31:13 [22931] User ID 0 PID 23133 called /org/fedorahosted/certmonger/requests/Request7:org.fedorahosted.certmonger.request.get_nickname. 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for 0x7fbe6b0c02e0:0x7fbe6b09b4e0. 2016-08-22 10:31:13 [23137] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:31:13 [23137] Not attempting to set NSS FIPS mode. 2016-08-22 10:31:13 [23137] Skipping NSS internal slot (NSS Generic Crypto Services). 2016-08-22 10:31:13 [23137] Found token 'NSS Certificate DB'. 2016-08-22 10:31:13 [23137] Located the key 'husky201'. 2016-08-22 10:31:13 [23137] Converted private key 'husky201' to public key. 2016-08-22 10:31:13 [23137] Key is an RSA key. 2016-08-22 10:31:13 [23137] Key size is 2048. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'NEWLY_ADDED_START_READING_CERT' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'NEWLY_ADDED_READING_CERT' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic from 11. 2016-08-22 10:31:13 [23138] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:31:13 [23138] Not attempting to set NSS FIPS mode. 2016-08-22 10:31:13 [23138] Found token 'NSS Generic Crypto Services'. 2016-08-22 10:31:13 [23138] Cert storage slot still needs user PIN to be set. 2016-08-22 10:31:13 [23138] Found token 'NSS Certificate DB'. 2016-08-22 10:31:13 [23138] Error locating certificate. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'NEWLY_ADDED_DECIDING' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. 2016-08-22 10:31:13 [22931] Request7('husky201') releasing writing lock 2016-08-22 10:31:13 [22931] Request7('husky201') has no certificate, will attempt enrollment using already-present key 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'NEED_CSR' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'GENERATING_CSR' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic from 11. 2016-08-22 10:31:13 [23139] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:31:13 [23139] Not attempting to set NSS FIPS mode. 2016-08-22 10:31:13 [23139] Skipping NSS internal slot (NSS Generic Crypto Services). 2016-08-22 10:31:13 [23139] Found token 'NSS Certificate DB'. 2016-08-22 10:31:13 [23139] Located the key 'husky201'. 2016-08-22 10:31:13 [23139] Converted private key 'husky201' to public key. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'HAVE_CSR' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'NEED_TO_SUBMIT' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'SUBMITTING' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic from 15. 2016-08-22 10:31:13 [22931] Certificate submission attempt complete. 2016-08-22 10:31:13 [22931] Child status = 16. 2016-08-22 10:31:13 [22931] Child output: "Error reading request, expected PKCS7 data. " 2016-08-22 10:31:13 [22931] Error reading request, expected PKCS7 data. 2016-08-22 10:31:13 [22931] Certificate not (yet?) issued. 2016-08-22 10:31:13 [22931] Request7('husky201') goes to a CA over SCEP, need to generate SCEP data. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'NEED_SCEP_DATA' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'GENERATING_SCEP_DATA' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic from 11. 2016-08-22 10:31:13 [23141] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:31:13 [23141] Not attempting to set NSS FIPS mode. 2016-08-22 10:31:13 [23141] Generating dummy key. 2016-08-22 10:31:13 [23141] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:31:13 [23141] Not attempting to set NSS FIPS mode. 2016-08-22 10:31:13 [23141] Skipping NSS internal slot (NSS Generic Crypto Services). 2016-08-22 10:31:13 [23141] Found token 'NSS Certificate DB'. 2016-08-22 10:31:13 [23141] Located the key 'husky201'. 2016-08-22 10:31:13 [23141] Converted private key 'husky201' to public key. 2016-08-22 10:31:13 [23141] Server does not support DES3, using DES. 2016-08-22 10:31:13 [23141] Server does not support better digests, using MD5. 2016-08-22 10:31:13 [23141] Generating PKCSREQ pkiMessage. 2016-08-22 10:31:13 [23141] Setting transaction ID "46763632748922674693649122043315271915873922247404248201497767686509312971065". 2016-08-22 10:31:13 [23141] Setting message type "19". 2016-08-22 10:31:13 [23141] Setting sender nonce. 2016-08-22 10:31:13 [23141] Signed data. 2016-08-22 10:31:13 [23141] Generating GetCertInitial pkiMessage. 2016-08-22 10:31:13 [23141] Setting transaction ID "46763632748922674693649122043315271915873922247404248201497767686509312971065". 2016-08-22 10:31:13 [23141] Setting message type "20". 2016-08-22 10:31:13 [23141] Setting sender nonce. 2016-08-22 10:31:13 [23141] Signed data. 2016-08-22 10:31:13 [23141] Signing using old key. 2016-08-22 10:31:13 [23141] Re-signing PKCSREQ message with old key. 2016-08-22 10:31:13 [23141] Re-signing GetCertInitial message with old key. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'HAVE_SCEP_DATA' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'NEED_TO_SUBMIT' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'SUBMITTING' 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic from 15. 2016-08-22 10:31:15 [22931] Certificate submission attempt complete. 2016-08-22 10:31:15 [22931] Child status = 3. 2016-08-22 10:31:15 [22931] Child output: "Error: failed to verify signature on server response. " 2016-08-22 10:31:15 [22931] Error: failed to verify signature on server response. 2016-08-22 10:31:15 [22931] Certificate not (yet?) issued. 2016-08-22 10:31:15 [22931] Request7('husky201') moved to state 'CA_UNREACHABLE' 2016-08-22 10:31:15 [22931] Will revisit Request7('husky201') in 604800 seconds. I recorded the client server communication and can clearly see that the server transmitted the certificate. When using jSCEP client I can successfully download certificates from that server with e.g. $ openssl req -key test.key -new -days 30 -out test.pemreq -outform PEM # end entity set to mx_pre2 $ java -jar target/jscepcli-1.0-SNAPSHOT-exe.jar --ca-identifier mx_kd3 --challenge abcd --csr-file test.pemreq --dn "CN=mx_pre2" --key-file test.key \ --url http://ejbca-test2.primekey.se:8080/ejbca/publicweb/apply/scep/mxratest/pkiclient.exe With certmonger I can successfully get a cert using another CA with an internal EJBCA server and this request: "getcert request -c Test_Sweden -v -d /tmp/nssdb -g 2048 -I husky100 -p /tmp/pwd.txt -n husky100 -L abcd -N CN='husky100' -s" id=KBCA ca_aka=SCEP (certmonger 0.78.6) ca_is_default=0 ca_type=EXTERNAL ca_external_helper=/usr/libexec/certmonger/scep-submit -u http://mucs70202.corp.knorr-bremse.com:8080/ejbca/publicweb/apply/scep/pkiclient.exe -i "iCOM%20Kunde1%20Dev%20SubCA" ca_capabilities=POSTPKIOperation,Renewal,SHA-1 scep_ca_identifier=KBCA ca_encryption_cert=-----BEGIN CERTIFICATE----- -----END CERTIFICATE----- ca_encryption_issuer_cert=-----BEGIN CERTIFICATE----- -----END CERTIFICATE----- ca_encryption_cert_pool=-----BEGIN CERTIFICATE----- -----END CERTIFICATE----- 2016-08-22 10:05:24 [21621] User ID 0 PID 22278 called /org/fedorahosted/certmonger:org.fedorahosted.certmonger.add_request. 2016-08-22 10:05:24 [22280] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:24 [22280] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:24 [22280] Skipping NSS internal slot (NSS Generic Crypto Services). 2016-08-22 10:05:24 [22280] Found token 'NSS Certificate DB'. 2016-08-22 10:05:24 [22280] Error locating a key. 2016-08-22 10:05:24 [22281] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:24 [22281] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:24 [22281] Found token 'NSS Generic Crypto Services'. 2016-08-22 10:05:24 [22281] Cert storage slot still needs user PIN to be set. 2016-08-22 10:05:24 [22281] Found token 'NSS Certificate DB'. 2016-08-22 10:05:24 [22281] Error locating certificate. 2016-08-22 10:05:24 [21621] Request2('husky100') starts in state 'NEWLY_ADDED' 2016-08-22 10:05:24 [21621] Request2('husky100') taking writing lock 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state 'NEWLY_ADDED_START_READING_KEYINFO' 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:24 [21621] Started Request2('husky100'). 2016-08-22 10:05:24 [21621] Queuing FD 8 for Read for 0x7fdf7bf25630:0x7fdf7bf33720. 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state 'NEWLY_ADDED_READING_KEYINFO' 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') on traffic from 11. 2016-08-22 10:05:24 [21621] Dequeuing FD 8 for Read for 0x7fdf7bf25630:0x7fdf7bf33720. 2016-08-22 10:05:24 [21621] Handling D-Bus traffic (Read) on FD 8 for 0x7fdf7bf25630. 2016-08-22 10:05:24 [21621] message 0x7fdf7bf25630(method_call)->org.fedorahosted.certmonger:/org/fedorahosted/certmonger/requests/Request2:org.fedorahosted.certmonger.request.get_nickname 2016-08-22 10:05:24 [21621] Pending GetConnectionUnixUser serial 1227 2016-08-22 10:05:24 [21621] Pending GetConnectionUnixProcessID serial 1228 2016-08-22 10:05:24 [21621] Queuing FD 8 for Read for 0x7fdf7bf25630:0x7fdf7bf2bc00. 2016-08-22 10:05:24 [21621] Dequeuing FD 8 for Read for 0x7fdf7bf25630:0x7fdf7bf2bc00. 2016-08-22 10:05:24 [21621] Handling D-Bus traffic (Read) on FD 8 for 0x7fdf7bf25630. 2016-08-22 10:05:24 [21621] message 0x7fdf7bf25630(method_return)->1227->819 2016-08-22 10:05:24 [21621] message 0x7fdf7bf25630(method_return)->1228->820 2016-08-22 10:05:24 [21621] User ID 0 PID 22278 called /org/fedorahosted/certmonger/requests/Request2:org.fedorahosted.certmonger.request.get_nickname. 2016-08-22 10:05:24 [21621] Queuing FD 8 for Read for 0x7fdf7bf25630:0x7fdf7bf33720. 2016-08-22 10:05:24 [22282] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:24 [22282] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:24 [22282] Skipping NSS internal slot (NSS Generic Crypto Services). 2016-08-22 10:05:24 [22282] Found token 'NSS Certificate DB'. 2016-08-22 10:05:24 [22282] Error locating a key. 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state 'NEWLY_ADDED_START_READING_CERT' 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state 'NEWLY_ADDED_READING_CERT' 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') on traffic from 11. 2016-08-22 10:05:25 [22283] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:25 [22283] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:25 [22283] Found token 'NSS Generic Crypto Services'. 2016-08-22 10:05:25 [22283] Cert storage slot still needs user PIN to be set. 2016-08-22 10:05:25 [22283] Found token 'NSS Certificate DB'. 2016-08-22 10:05:25 [22283] Error locating certificate. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'NEWLY_ADDED_DECIDING' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:25 [21621] Request2('husky100') releasing writing lock 2016-08-22 10:05:25 [21621] Request2('husky100') has no key or certificate, will generate keys and attempt enrollment 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'NEED_KEY_PAIR' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:25 [21621] Request2('husky100') taking writing lock 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'GENERATING_KEY_PAIR' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic from 11. 2016-08-22 10:05:25 [22284] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:25 [22284] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:25 [22284] Found token 'NSS Certificate DB'. 2016-08-22 10:05:25 [22284] Generating key pair. 2016-08-22 10:05:25 [22284] Nickname "husky100" appears to be unused. 2016-08-22 10:05:25 [22284] Set nickname "husky100" on private key. 2016-08-22 10:05:25 [21621] Request2('husky100') releasing writing lock 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'HAVE_KEY_PAIR' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'NEED_KEYINFO' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'READING_KEYINFO' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic from 11. 2016-08-22 10:05:25 [22285] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:25 [22285] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:25 [22285] Skipping NSS internal slot (NSS Generic Crypto Services). 2016-08-22 10:05:25 [22285] Found token 'NSS Certificate DB'. 2016-08-22 10:05:25 [22285] Located the key 'husky100'. 2016-08-22 10:05:25 [22285] Converted private key 'husky100' to public key. 2016-08-22 10:05:25 [22285] Key is an RSA key. 2016-08-22 10:05:25 [22285] Key size is 2048. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'HAVE_KEYINFO' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'NEED_CSR' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'GENERATING_CSR' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic from 11. 2016-08-22 10:05:25 [22286] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:25 [22286] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:25 [22286] Skipping NSS internal slot (NSS Generic Crypto Services). 2016-08-22 10:05:25 [22286] Found token 'NSS Certificate DB'. 2016-08-22 10:05:25 [22286] Located the key 'husky100'. 2016-08-22 10:05:25 [22286] Converted private key 'husky100' to public key. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'HAVE_CSR' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'NEED_TO_SUBMIT' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'SUBMITTING' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic from 15. 2016-08-22 10:05:25 [21621] Certificate submission attempt complete. 2016-08-22 10:05:25 [21621] Child status = 16. 2016-08-22 10:05:25 [21621] Child output: "Error reading request, expected PKCS7 data. " 2016-08-22 10:05:25 [21621] Error reading request, expected PKCS7 data. 2016-08-22 10:05:25 [21621] Certificate not (yet?) issued. 2016-08-22 10:05:25 [21621] Request2('husky100') goes to a CA over SCEP, need to generate SCEP data. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'NEED_SCEP_DATA' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'GENERATING_SCEP_DATA' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic from 11. 2016-08-22 10:05:25 [22288] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:25 [22288] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:25 [22288] Generating dummy key. 2016-08-22 10:05:25 [22288] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:25 [22288] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:25 [22288] Skipping NSS internal slot (NSS Generic Crypto Services). 2016-08-22 10:05:25 [22288] Found token 'NSS Certificate DB'. 2016-08-22 10:05:25 [22288] Located the key 'husky100'. 2016-08-22 10:05:25 [22288] Converted private key 'husky100' to public key. 2016-08-22 10:05:25 [22288] Server does not support DES3, using DES. 2016-08-22 10:05:25 [22288] Server does not support better digests, using MD5. 2016-08-22 10:05:25 [22288] Generating PKCSREQ pkiMessage. 2016-08-22 10:05:25 [22288] Setting transaction ID "89399340103492129363376569585892061602695437784280139265051808388486717974760". 2016-08-22 10:05:25 [22288] Setting message type "19". 2016-08-22 10:05:25 [22288] Setting sender nonce. 2016-08-22 10:05:25 [22288] Signed data. 2016-08-22 10:05:25 [22288] Generating GetCertInitial pkiMessage. 2016-08-22 10:05:25 [22288] Setting transaction ID "89399340103492129363376569585892061602695437784280139265051808388486717974760". 2016-08-22 10:05:25 [22288] Setting message type "20". 2016-08-22 10:05:25 [22288] Setting sender nonce. 2016-08-22 10:05:25 [22288] Signed data. 2016-08-22 10:05:25 [22288] Signing using old key. 2016-08-22 10:05:25 [22288] Re-signing PKCSREQ message with old key. 2016-08-22 10:05:25 [22288] Re-signing GetCertInitial message with old key. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'HAVE_SCEP_DATA' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'NEED_TO_SUBMIT' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'SUBMITTING' 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic from 15. 2016-08-22 10:05:26 [21621] Certificate submission attempt complete. 2016-08-22 10:05:26 [21621] Child status = 0. 2016-08-22 10:05:26 [21621] Child output: "-----BEGIN PKCS7----- MIAGCSqGSIb3DQEHA6CAMIACAQAxggFUMIIBUAIBADA4MBMxETAPBgNVBAMTCGh1 c2t5MTAwAiEAxaY7vcruKj5BOCTGw5wQBTpMC0GpLQ5rQJvfM6bjKOgwDQYJKoZI hvcNAQEBBQAEggEAF8VwCqiExnQyPQvdPV8vYFIvV0OGJ5AuyurIQQ0y3zeb6Jjc h4j6LilwV0BnUjdH9G2t4gGWUbbUVxciaXy0lgcZnO7C39ptc8tPfcfnD5gwRXdj jLjWTRa6IBhBvgZS6/tQ1uiWXygSnTVl9renZSBixKrnUSaRO5vHl4IsMWp4J8/p 39DY2zncvP/oq4bMKe5priZEjgbZkgFI9IuleQM80pzTHayWlChx2M5Cg5pDrBLc k0lZeVLQ6Vg5V3yRGSsXNrxkexYZkRFGQkZ/6gsLmj1nPPVGjhjbtoEGtQZGpXaW xD+nWyv2TUDge1OzIYj326scX3z3+YXcw2J23zCABgkqhkiG9w0BBwEwEQYFKw4D AgcECJgYnlIa2DxtoIAEggNgaTC2AhLM52T8guE2jr4YTK1UlcwDpN8yRJNRyuK7 vtDjx5aPx3+qTRJAOdeulV3pYK+3dpmddJoePGFpW/MaKBgAOpZVi/gk6LxnfKG4 l+gwPR7y3EyXXCyank553tceF08lPoPMfkRCe01le5EW2PKKH9y7JeqvVkxIjhI8 vaYKmARCLAtC4fXexjnjMxFKISctLTIJqqDfCn6T7h2j61jIAB4wABmTKjh1fwp5 +bR+enbCG33KY9taeDHvgAYl0XOi8IQ370dI57I72383RCcQdAa9qdMSnhquMyZL GS1zBnWrW9wMbMWkIRjR+1nGguS+6qBP4IekOuifoi/LHkSz/uOUuEi0cintRRy6 TsQEimydfIRfGrpcpaPCksHYUp/QZOSsQz9xAb/u6xMJMYRxKEw8q80xSniZP+dr HwfRThoJuxZcr3bpnRuEt2fYd1MgASeNTuZyLV4UJgdAZKAid74S0oi20OTSJyJE +GScqV/loZ4kJByE7fk3ZzCEWjOBhbzFzkoJ0vCxnRsq2eiyiTmTQvl4CM24q84f SNvUT3UE2NryGV8DSVuyUb0HX97x8Ii0l+pcciylWWy0W5qBhVlo5ns8aDfP4xqg blXv13hVIZPRs2KYFinK1ptOf2dBdYI8AFRx4eq85HGTd4J9yy5qIPjMfTVCNJz1 GLHFCIAQrClFehHvVrny0tO88B9/Xky9I6ReRPdz8kZ6GBCkTBS3I+4Km7uyo2Bd XE5XlBJhaVboApZIwLNaf24eqH/L9pG6O+BhzKQEFqDYmpIzWslIsBqtMPFWD5E/ x/v8O2Pj0b+Tmkky+VYv8gdEkOy6LPX2J4YH86PljJDEoSqhmSeeVFuGCbaRa60L NevoUzoQ3qCl/Brob7nDrOWeE1uJBWcDBs/CeFUvB0mfniIp0iDUOiTpWVm7drwv EMObPE+5SijzwFnj5HIgSpmHZUjFR9JcRfuG6E3u7BrDl1wS6U5lfb7Oqro2T6PF DB1+bL7NzCqF1nOYEDELOSrMxvk8/JQMxkBdrNx592FunoMEz8oAPbK5Lvt8oqE8 YcULZMb56Zp4S/L4P/8jV5KB9peXhxWhvU4qqXGeBBQSjggBxAURUZni5HaRrzv4 nUIyUuaf0fv3QY3tIi9hKaH8AAAAAAAAAAAAAA== -----END PKCS7----- " 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on traffic from 11. 2016-08-22 10:05:26 [22292] Postprocessing output "-----BEGIN PKCS7----- MIAGCSqGSIb3DQEHA6CAMIACAQAxggFUMIIBUAIBADA4MBMxETAPBgNVBAMTCGh1 c2t5MTAwAiEAxaY7vcruKj5BOCTGw5wQBTpMC0GpLQ5rQJvfM6bjKOgwDQYJKoZI hvcNAQEBBQAEggEAF8VwCqiExnQyPQvdPV8vYFIvV0OGJ5AuyurIQQ0y3zeb6Jjc h4j6LilwV0BnUjdH9G2t4gGWUbbUVxciaXy0lgcZnO7C39ptc8tPfcfnD5gwRXdj jLjWTRa6IBhBvgZS6/tQ1uiWXygSnTVl9renZSBixKrnUSaRO5vHl4IsMWp4J8/p 39DY2zncvP/oq4bMKe5priZEjgbZkgFI9IuleQM80pzTHayWlChx2M5Cg5pDrBLc k0lZeVLQ6Vg5V3yRGSsXNrxkexYZkRFGQkZ/6gsLmj1nPPVGjhjbtoEGtQZGpXaW xD+nWyv2TUDge1OzIYj326scX3z3+YXcw2J23zCABgkqhkiG9w0BBwEwEQYFKw4D AgcECJgYnlIa2DxtoIAEggNgaTC2AhLM52T8guE2jr4YTK1UlcwDpN8yRJNRyuK7 vtDjx5aPx3+qTRJAOdeulV3pYK+3dpmddJoePGFpW/MaKBgAOpZVi/gk6LxnfKG4 l+gwPR7y3EyXXCyank553tceF08lPoPMfkRCe01le5EW2PKKH9y7JeqvVkxIjhI8 vaYKmARCLAtC4fXexjnjMxFKISctLTIJqqDfCn6T7h2j61jIAB4wABmTKjh1fwp5 +bR+enbCG33KY9taeDHvgAYl0XOi8IQ370dI57I72383RCcQdAa9qdMSnhquMyZL GS1zBnWrW9wMbMWkIRjR+1nGguS+6qBP4IekOuifoi/LHkSz/uOUuEi0cintRRy6 TsQEimydfIRfGrpcpaPCksHYUp/QZOSsQz9xAb/u6xMJMYRxKEw8q80xSniZP+dr HwfRThoJuxZcr3bpnRuEt2fYd1MgASeNTuZyLV4UJgdAZKAid74S0oi20OTSJyJE +GScqV/loZ4kJByE7fk3ZzCEWjOBhbzFzkoJ0vCxnRsq2eiyiTmTQvl4CM24q84f SNvUT3UE2NryGV8DSVuyUb0HX97x8Ii0l+pcciylWWy0W5qBhVlo5ns8aDfP4xqg blXv13hVIZPRs2KYFinK1ptOf2dBdYI8AFRx4eq85HGTd4J9yy5qIPjMfTVCNJz1 GLHFCIAQrClFehHvVrny0tO88B9/Xky9I6ReRPdz8kZ6GBCkTBS3I+4Km7uyo2Bd XE5XlBJhaVboApZIwLNaf24eqH/L9pG6O+BhzKQEFqDYmpIzWslIsBqtMPFWD5E/ x/v8O2Pj0b+Tmkky+VYv8gdEkOy6LPX2J4YH86PljJDEoSqhmSeeVFuGCbaRa60L NevoUzoQ3qCl/Brob7nDrOWeE1uJBWcDBs/CeFUvB0mfniIp0iDUOiTpWVm7drwv EMObPE+5SijzwFnj5HIgSpmHZUjFR9JcRfuG6E3u7BrDl1wS6U5lfb7Oqro2T6PF DB1+bL7NzCqF1nOYEDELOSrMxvk8/JQMxkBdrNx592FunoMEz8oAPbK5Lvt8oqE8 YcULZMb56Zp4S/L4P/8jV5KB9peXhxWhvU4qqXGeBBQSjggBxAURUZni5HaRrzv4 nUIyUuaf0fv3QY3tIi9hKaH8AAAAAAAAAAAAAA== -----END PKCS7----- ". 2016-08-22 10:05:26 [22292] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:26 [22292] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:26 [22292] Skipping NSS internal slot (NSS Generic Crypto Services). 2016-08-22 10:05:26 [22292] Found token 'NSS Certificate DB'. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag 2016-08-22 10:05:26 [22292] error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error 2016-08-22 10:05:26 [22292] error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag 2016-08-22 10:05:26 [22292] error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. 2016-08-22 10:05:26 [22292] Succeeded in decrypting enveloped data. 2016-08-22 10:05:26 [22292] Succeeded in decrypting enveloped data. 2016-08-22 10:05:26 [21621] Certificate submission postprocessing complete. 2016-08-22 10:05:26 [21621] Child status = 0. 2016-08-22 10:05:26 [21621] Child output: "{"certificate":"-----BEGIN CERTIFICATE-----\nMIIDKjCCAhKgAwIBAgIIBVULrGtczBowDQYJKoZIhvcNAQEFBQAwIDEeMBwGA1UE\nAwwVaUNPTSBLdW5kZTEgRGV2IFN1YkNBMB4XDTE2MDgyMjA3NTUyNloXDTI2MDYw\nOTE0MjYxMVowEzERMA8GA1UEAwwIaHVza3kxMDAwggEiMA0GCSqGSIb3DQEBAQUA\nA4IBDwAwggEKAoIBAQCwj6TZXwh2TD1UJuEc/LhjgUF91BJ4OOpjt2uOyfTsGaFO\nDykz0tEWyXRk7mkHQeqC/isVD0CYz6bhks2HwwqMAIc37eaz/uEIPQu4rz59gUMl\nVkh93YOtX2JlsQ0y0QPuwIGgb3Z1NX8MbhlE0GpLrb2vY8Y0TpBjwGpbagaMRPgz\nyP2v62jau9xn+72VTjOxNImJH/8V1UTDl1gt0lR2XH5dMeo+weVW8ZUvgDykhQDj\nq4V/trRW+556owhPv2ALBpuubp99d2rfPSdWnLg7JCtpIEIGq9KcEIfV1Bq/d4zb\n3PVrb1xZIb2vCOYyijUr8OCpgMslTM1WiKdIw9GTAgMBAAGjdTBzMAwGA1UdEwEB\n/wQCMAAwHwYDVR0jBBgwFoAUp+pgIuSdJoXPRmZ6unXbKtfB2NowEwYDVR0lBAww\nCgYIKwYBBQUHAwIwHQYDVR0OBBYEFCKFlaNB18Tf7Njwy/8I1aDPge3DMA4GA1Ud\nDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAho5avfYElYPaUxr9diXxG4aA\nVijNIiGXa6FmOwmMmR2h2UUqn11doNbkR+Zv4FFjMqdlWQh4aMLhn6Z0+ahSx3NY\nHG0saJfV88loRb+zC03yOyPIjEmFo4d2Vc+CsXAQ49ElHVKjqqC3JaMrma/EfMQ2\nW6Sc8x55smgPXjPLf8VytHdjH/ZeCDFbBYqs8CS0JbjP2UppEjwWAv4r8QH8VWuz\n97kxRpXFVTXb/gJUCxNqJRCU1aFTfO1L6x9BzfVKJX73nyAuQmZ+090PJIFCTTx/\nexdeoX0EBPeGmV7XjAO5GqGq+P6i3oeJ/Z8Kvug0XzlUSc55SMbc+z2B07GVIA==\n-----END CERTIFICATE-----\n","key_checked":true} " 2016-08-22 10:05:26 [21621] Issued certificate is "-----BEGIN CERTIFICATE----- MIIDKjCCAhKgAwIBAgIIBVULrGtczBowDQYJKoZIhvcNAQEFBQAwIDEeMBwGA1UE AwwVaUNPTSBLdW5kZTEgRGV2IFN1YkNBMB4XDTE2MDgyMjA3NTUyNloXDTI2MDYw OTE0MjYxMVowEzERMA8GA1UEAwwIaHVza3kxMDAwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCwj6TZXwh2TD1UJuEc/LhjgUF91BJ4OOpjt2uOyfTsGaFO Dykz0tEWyXRk7mkHQeqC/isVD0CYz6bhks2HwwqMAIc37eaz/uEIPQu4rz59gUMl Vkh93YOtX2JlsQ0y0QPuwIGgb3Z1NX8MbhlE0GpLrb2vY8Y0TpBjwGpbagaMRPgz yP2v62jau9xn+72VTjOxNImJH/8V1UTDl1gt0lR2XH5dMeo+weVW8ZUvgDykhQDj q4V/trRW+556owhPv2ALBpuubp99d2rfPSdWnLg7JCtpIEIGq9KcEIfV1Bq/d4zb 3PVrb1xZIb2vCOYyijUr8OCpgMslTM1WiKdIw9GTAgMBAAGjdTBzMAwGA1UdEwEB /wQCMAAwHwYDVR0jBBgwFoAUp+pgIuSdJoXPRmZ6unXbKtfB2NowEwYDVR0lBAww CgYIKwYBBQUHAwIwHQYDVR0OBBYEFCKFlaNB18Tf7Njwy/8I1aDPge3DMA4GA1Ud DwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAho5avfYElYPaUxr9diXxG4aA VijNIiGXa6FmOwmMmR2h2UUqn11doNbkR+Zv4FFjMqdlWQh4aMLhn6Z0+ahSx3NY HG0saJfV88loRb+zC03yOyPIjEmFo4d2Vc+CsXAQ49ElHVKjqqC3JaMrma/EfMQ2 W6Sc8x55smgPXjPLf8VytHdjH/ZeCDFbBYqs8CS0JbjP2UppEjwWAv4r8QH8VWuz 97kxRpXFVTXb/gJUCxNqJRCU1aFTfO1L6x9BzfVKJX73nyAuQmZ+090PJIFCTTx/ exdeoX0EBPeGmV7XjAO5GqGq+P6i3oeJ/Z8Kvug0XzlUSc55SMbc+z2B07GVIA== -----END CERTIFICATE----- ". 2016-08-22 10:05:26 [21621] Certificate issued (0 chain certificates, 0 roots). 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'NEED_TO_SAVE_CERT' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:26 [21621] Request2('husky100') taking writing lock 2016-08-22 10:05:26 [21621] No hooks set for pre-save command. 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'START_SAVING_CERT' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'SAVING_CERT' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on traffic from 11. 2016-08-22 10:05:26 [22293] No duplicate nickname entries. 2016-08-22 10:05:26 [22293] No duplicate subject name entries. 2016-08-22 10:05:26 [22293] Imported certificate "husky100", got nickname "husky100". 2016-08-22 10:05:26 [22293] Removed name from old key. 2016-08-22 10:05:26 [22293] Error shutting down NSS. 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'SAVED_CERT' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'NEED_TO_SAVE_CA_CERTS' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'START_SAVING_CA_CERTS' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'SAVING_CA_CERTS' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on traffic from 11. 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'NEED_TO_READ_CERT' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'READING_CERT' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on traffic from 11. 2016-08-22 10:05:26 [22295] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:26 [22295] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:26 [22295] Found token 'NSS Generic Crypto Services'. 2016-08-22 10:05:26 [22295] Cert storage slot still needs user PIN to be set. 2016-08-22 10:05:26 [22295] Found token 'NSS Certificate DB'. 2016-08-22 10:05:26 [22295] Located the certificate "husky100". 2016-08-22 10:05:26 [22295] Read value "0" from "/proc/sys/crypto/fips_enabled". 2016-08-22 10:05:26 [22295] Not attempting to set NSS FIPS mode. 2016-08-22 10:05:26 [21621] No hooks set for post-save command. 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'NEED_TO_NOTIFY_ISSUED_SAVED' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. 2016-08-22 10:05:26 [21621] Request2('husky100') releasing writing lock 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'NOTIFYING_ISSUED_SAVED' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on traffic from 11. 2016-08-22 10:05:26 [22296] 0x1d Certificate named "husky100" in token "NSS Certificate DB" in database "/tmp/nssdb" issued by CA and saved. 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'MONITORING' 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') soon. 2016-08-22 10:05:31 [21621] Will revisit Request2('husky100') in 86400 seconds. Besides this "Error reading request, expected PKCS7 data" which always shows up and "Error decrypting bulk key: SEC_ERROR_BAD_DATA" errors (?) finally the cert is issued and stored into the nSS DB. Certificate: Data: Version: 3 (0x2) Serial Number: 8344117917752670949 (0x73cc4309839ebae5) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=mx_kd3 Validity Not Before: Aug 19 16:03:29 2016 GMT Not After : Aug 2 15:23:36 2017 GMT Subject: CN=mx_pre2 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:89:01:fc:d4:a0:5c:df:8d:b6:f6:e3:49:8c:93: 77:7a:1e:26:34:4e:37:90:c3:6c:b0:e0:5d:a7:47: 8e:81:8f:d8:04:d5:c0:03:26:1a:a5:49:c8:82:98: 40:25:34:2e:43:c5:7d:cc:10:0e:b0:13:26:25:c0: 3d:87:15:fc:7f:90:6d:3d:2f:d6:ce:31:1f:af:38: 3f:8c:e9:fc:01:4c:a6:c5:3f:82:cb:c0:f8:8c:e7: 30:75:ba:68:b8:69:a6:6b:6c:04:a3:58:fb:b0:10: 94:4b:a2:f6:bd:24:f7:75:97:c0:f2:4e:ee:d9:df: 7b:61:8b:46:a9:d4:46:96:05:31:e5:60:87:3e:8d: 9b:8e:b2:f6:0f:03:1f:b7:49:1d:83:ec:9f:66:b1: f9:76:dd:dd:c5:b6:fa:52:5f:56:ce:2e:00:87:11: 90:6d:ba:c3:d7:fd:19:e0:64:c1:5d:0b:62:59:ad: 61:80:a7:76:d4:08:39:6b:2e:6f:05:68:c9:10:b4: 9f:3e:b9:d0:63:9f:7d:e1:a7:74:4f:f8:f4:17:34: f5:bf:ab:c6:bf:b9:48:80:59:ec:00:41:de:8b:46: 30:9d:8c:2b:d4:f3:2e:bd:39:e6:da:cd:d9:32:04: 55:04:29:26:66:0f:ac:ac:d2:bf:b1:19:56:62:0a: 56:69 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: D7:06:53:64:27:62:69:3B:ED:79:B2:6A:D8:94:DD:EE:B6:9C:51:44 X509v3 Basic Constraints: critical CA:FALSE X509v3 Authority Key Identifier: keyid:8C:DB:52:66:8F:60:01:FA:58:8D:82:06:01:25:9C:2C:7D:D0:A0:14 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication Signature Algorithm: sha1WithRSAEncryption 45:a1:0c:9b:7b:20:31:0a:90:53:21:b8:d5:e2:05:0f:29:10: 77:d6:3a:44:38:9d:4a:d0:19:30:99:b9:41:0e:b1:4b:0e:c2: 35:36:ce:98:5f:0a:54:88:3b:91:d1:fb:df:e5:6f:57:f9:04: 0d:51:bf:c5:50:c3:c6:4d:88:a0:73:31:99:63:85:69:81:66: 93:5c:c3:bf:3f:ef:50:cc:db:de:fe:95:43:64:f0:2c:66:c1: f0:64:6f:8d:75:53:54:48:28:92:05:e1:21:a2:d6:fe:e3:1e: 5a:af:87:ba:45:06:39:47:5a:b8:df:1c:d8:cc:cf:6a:4a:ac: 08:92:7c:5b:08:9b:d5:0b:6d:49:33:c3:8f:a3:2c:50:4e:50: ae:d3:61:27:09:8c:de:c3:04:91:e0:f9:0e:aa:63:49:84:5e: cc:03:78:14:6e:cc:c3:5e:46:3b:56:6c:ae:20:7b:ce:51:8a: 78:eb:6b:4b:80:45:45:f3:3f:14:b6:d0:6a:99:d4:46:ad:d2: 0f:4d:99:4d:31:34:1f:4f:a3:19:92:45:8f:89:29:7e:4e:e7: 43:b2:15:4d:df:8a:66:70:c4:5d:b0:e3:d8:13:77:c2:51:98: 67:7d:b4:3c:95:71:54:05:06:1f:69:ae:fc:b1:00:b4:88:84: da:e0:85:ae subject= /CN=mx_pre2 issuer= /CN=mx_kd3 -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiQH81KBc34229uNJjJN3 eh4mNE43kMNssOBdp0eOgY/YBNXAAyYapUnIgphAJTQuQ8V9zBAOsBMmJcA9hxX8 f5BtPS/WzjEfrzg/jOn8AUymxT+Cy8D4jOcwdbpouGmma2wEo1j7sBCUS6L2vST3 dZfA8k7u2d97YYtGqdRGlgUx5WCHPo2bjrL2DwMft0kdg+yfZrH5dt3dxbb6Ul9W zi4AhxGQbbrD1/0Z4GTBXQtiWa1hgKd21Ag5ay5vBWjJELSfPrnQY5994ad0T/j0 FzT1v6vGv7lIgFnsAEHei0YwnYwr1PMuvTnm2s3ZMgRVBCkmZg+srNK/sRlWYgpW aQIDAQAB -----END PUBLIC KEY----- SHA1 Fingerprint=C3:B6:32:E9:70:E8:0F:98:A5:77:8E:96:13:5B:F8:40:63:37:29:7E So the question is why certmonger fails to verify signature on server response depending on which server I try. What is included in the checks ? hostname of clients/servers? How can I debug this ? I'm not an experienced C programmer and was just able to apply that GetCACertchain fix in scep.c and build certmonger with that. Peter automechanika - 13.09.-17.09.2016 - Messe Frankfurt - Hall 3.0 - Stand G98 + E91 InnoTrans - 20.09.-23.09.2016 - Messe Berlin - Hall 1.2b - Stand 104 + 210 IAA - 22.09.-29.09.2016 - Messe Hannover - Hall 17 - Stand A30 + D131 Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Mon Aug 22 11:18:25 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 22 Aug 2016 13:18:25 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: <57A07FE4.8000904@redhat.com> References: <57723947.2090508@redhat.com> <5772622C.9000205@redhat.com> <579FB51F.6030808@redhat.com> <98a90ec8-fa79-dd36-57dc-053204c29506@redhat.com> <57A07FE4.8000904@redhat.com> Message-ID: ping for review On 08/02/2016 01:11 PM, Oleg Fayans wrote: > Hi Martin, > > I did! Thank you! > > On 08/02/2016 12:31 PM, Martin Basti wrote: >> >> >> On 01.08.2016 22:46, Oleg Fayans wrote: >>> The test was redesigned so that it actually tests against an AD user. >>> cleanly applies, passes lint and passes >>> >>> https://paste.fedoraproject.org/399504/00843641/ >> >> Okay >> >> Did you forget to send patches? >> >> Martin^2 >>> >>> >>> On 06/28/2016 01:40 PM, Oleg Fayans wrote: >>>> Patch-0050 rebased against latest upstream branch >>>> >>>> On 06/28/2016 10:45 AM, Oleg Fayans wrote: >>>>> Passing test output: >>>>> >>>>> https://paste.fedoraproject.org/385774/71035231/ >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbabinsk at redhat.com Mon Aug 22 11:39:46 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 22 Aug 2016 13:39:46 +0200 Subject: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes In-Reply-To: <14dd21f5-560f-c78a-f333-24af67f7f8ea@redhat.com> References: <20160815160607.wky5extyyrmydgb4@redhat.com> <20160815160648.o2afooo4w5vycmt6@redhat.com> <20160817112037.phvkgo3zbw55gujk@redhat.com> <14dd21f5-560f-c78a-f333-24af67f7f8ea@redhat.com> Message-ID: On 08/18/2016 05:13 PM, Martin Babinsky wrote: > On 08/18/2016 01:25 PM, Martin Babinsky wrote: >> On 08/17/2016 01:20 PM, Alexander Bokovoy wrote: >>> On Wed, 17 Aug 2016, Martin Babinsky wrote: >>>> Hi Alexander, >>>> >>>> patch 207: LGTM, but I have a feeling that the patch should be linked >>>> to both #6021 and #6076 so that it is not lost during backports. >>>> >>>> patch 218: >>>> >>>> ipalib/errors.py: >>>> >>>> 1.) >>>> I'm not sure if TrustTopologyConflictError should inherit from >>>> InvocationError. The semantics of InvocationError implies that >>>> something was wrong when trying to invoke the command (a param failed >>>> to validate/convert, incorrect number of args, etc.), while this is >>>> more of an exception during command execution (no. and type of params >>>> was correct, command started to execute but encountered an error >>>> condition). Thus I think it should inherit from ExecutionError. CC'ing >>>> Jan for more thoughts on this. >>> Using ExecutionError would work to me too, as long as we display the >>> error to a user. >>>> Why is TrustTopologyConflictSolved listed amogn public errors? Since >>>> it is used only in dcerpc.py to restart trust establishment after >>>> resolving conflicts, it should be a private exception in dcerpc.py for >>>> this purpose. >>> I originally wanted to make it a warning -- i.e. if we fixed the >>> conflict, return the result and show the warning that we did solve the >>> conflict. After all, the code is modifying another trusted forest's >>> topology on behalf of the user. I can move the error class to dcerpc.py >>> >>> >>>> 3.) >>>> Also please split the exception format string like this so that the >>>> line is not too long (there is not much we can do about doctest so >>>> leave that line as it is): >>>> >>>> @@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError): >>>> """ >>>> >>>> errno = 3017 >>>> - format = _("Forest '%(forest)s' has existing trust to forest(s) >>>> %(domains)s which prevents a trust to '%(conflict)s'") >>>> + format = _("Forest '%(forest)s' has existing trust to forest(s) " >>>> + "%(domains)s which prevents a trust to '%(conflict)s'") >>>> >>>> Do not worry about gettext, it can handle it just fine, there are >>>> plenty of examples in server plugins, for example. >>> Done. >>> >>>> ipaserver/dcerpc.py: >>>> >>>> 1.) >>>> >>>> I think that instead of returning result and raising >>>> TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' >>>> can raise this exception directly. You can have an empty list defined >>>> at the beginning instead of 'result list', append unresolvable >>>> conflicts to it and then at the end of the method check if it is >>>> non-empty and raise the exception. >>> Good suggestion, fixed. >>> >>>> >>>> 2.) >>>> >>>> + # In the code below: >>>> + # self -- the forest we establish trust to >>>> + # another_domain -- a forest that establishes trust to 'self' >>>> + # cinfo -- lsa_ForestTrustCollisionInfo structure that contain >>>> + # set of of lsa_ForestTrustCollisionRecord structures >>>> I would add this directly into the method docstring: >>>> >>>> """ >>>> ... >>>> >>>> :param self: the forest we establish trust to >>>> :param another_domain: a forest that establishes trust to 'self' >>>> :param cinfo: lsa_ForestTrustCollisionInfo structure that contain >>>> set of of lsa_ForestTrustCollisionRecord structures >>>> """ >>> Added. >>> >>>> Additionally, the behavior specifed in previous comment can be added >>>> using :raises: stanza: >>>> >>>> """ >>>> :raises: errors.TrustTopologyConflictError if there are unresolvable >>>> namespace conflicts between trusted domains >>>> """ >>> Added. >>> >>>> >>>> 3.) >>>> >>>> rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to >>>> simplify code in 'update_ftinfo' like this: >>>> >>>> """ >>>> - res = self.clear_ftinfo_conflict(another_domain, >>>> cinfo) >>>> - if len(res[1]) != 0: >>>> - domains = [x.name.string for x in res[1]] >>>> - raise errors.TrustTopologyConflictError( >>>> - target=self.info['dns_domain'], >>>> - >>>> conflict=another_domain.info['dns_domain'], >>>> - domains=domains) >>>> - else: >>>> - raise errors.TrustTopologyConflictSolved( >>>> - target=self.info['dns_domain'], >>>> - >>>> conflict=another_domain.info['dns_domain']) >>>> + self.clear_ftinfo_conflict(another_domain, cinfo) >>>> + raise errors.TrustTopologyConflictSolved( >>>> + target=self.info['dns_domain'], >>>> + conflict=another_domain.info['dns_domain']) >>>> """ >>> done. >>> >>>> >>>> Patch 218: >>>> >>>> 1.) >>>> typo in the commit message: >>>> >>>> """ >>>> ... >>>> suffixes are forest-wide, there *are could be* user accounts in the >>>> ... >>>> """ >>> Fixed. >>> >>> Updated patches attached. >> >> PATCH 207: ACK, I am attaching rebased version for ipa-4-3. Please check >> if the rebase is correct. >> >> PATCH 218: I am attaching rebased version for control. Unfortunately, I >> am unable to properly test conflict resolution due to reasons beyond my >> control but it does not break any ordinary workflows and code looks OK, >> so ACK. >> > > I have noticed that raising of TrustTopologyConflictSolved is broken. I > have changed the base class to Exception and it works. Attaching patches > with the change. > >> PATCH 219: ACK >> >> >> > > > > Linked patch 207 to ticket 6076: 207 and 218: Pushed to master: 6332cb3125a42c1bf2680309b5480155e40d3d87 Pushed to ipa-4-3: 324d5aa1d09431c64d817f628b18b01a12253ccf patch 219: Pushed to master: 9b3819ea94d3fd8e866d38ccba2051446d057ecd -- Martin^3 Babinsky From ftweedal at redhat.com Mon Aug 22 11:51:51 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 22 Aug 2016 21:51:51 +1000 Subject: [Freeipa-devel] invoking ipa-certupdate from within installer In-Reply-To: <4276987b-e546-455f-b977-bd1341703229@redhat.com> References: <20160822073757.GW3877@dhcp-40-8.bne.redhat.com> <4276987b-e546-455f-b977-bd1341703229@redhat.com> Message-ID: <20160822115151.GX3877@dhcp-40-8.bne.redhat.com> On Mon, Aug 22, 2016 at 10:00:57AM +0200, Jan Cholasta wrote: > Hi, > > On 22.8.2016 09:37, Fraser Tweedale wrote: > > #6019 requires adding tracking requests for existing lightweight CAs > > as part of replica installation. ipa-certupdate has logic to do > > this. > > > > Before I go ahead and implement, there are a few approaches I want > > to mention and seek feedback from team members before I commit to > > one. > > > > 1. invoke ipa-certupdate as a subprocess, from > > CAInstance.configure_replica. This is the simplest approach. Not > > much else to say about it, really :) > > > > 2. invoke ipa-certupdate's main() from the installer. This is > > slightly more work because currently it would fail due to API > > already having been initialised. > > > > 3. extract all logic for adding tracking requests such that it can > > be invoked separately; then refactor ipa-certupdate to call it as > > well as calling it from CAInstance.configure_replica. This is the > > most work. > > > > I lean towards (1) or (3). If you wish it to be done a certain way > > say your piece. > > (4) Extract the relevant code from ipa-certupdate into a separate function > and call it from CAInstance.configure_replica(). > > I would not go with (1) or (2) because it does more than track the certs. I > would also not go with (3) because it requires extensive changes not > suitable for 4.4. > (4) is exactly what I meant in (3) - (I was too vague). (3/4) it is. Thanks for input. From ldoudova at redhat.com Mon Aug 22 11:51:56 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 22 Aug 2016 13:51:56 +0200 Subject: [Freeipa-devel] [PATCHES 0038][Tests] ID views does not recognize ipakrboktoauthasdelegate attribute Message-ID: Hi, due to implementation of [1] some ID views tests fail because they do not recognize ipakrboktoauthasdelegate attribute. Providing fix for this. Ticket: https://fedorahosted.org/freeipa/ticket/6241 Lenka [1] https://fedorahosted.org/freeipa/ticket/5764 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0038-Tests-ID-views-tests-do-not-recognize-ipakrboktoauth.patch Type: text/x-patch Size: 3071 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Aug 22 11:54:12 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 13:54:12 +0200 Subject: [Freeipa-devel] [freeipa PR#3] User add fix #6199 (synchronize) In-Reply-To: References: Message-ID: mbasti-rh's pull request #3: "User add fix #6199" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/3 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-3.patch URL: From akasurde at redhat.com Mon Aug 22 11:58:57 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Mon, 22 Aug 2016 17:28:57 +0530 Subject: [Freeipa-devel] [Patch 0019] Corrected minor spell check in AD Trust information doc messages Message-ID: Hi All, Please find the patch attached. It's a minor spelling correction so, I have not created ticket for this. -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0019-Corrected-minor-spell-check-in-AD-Trust-information.patch Type: text/x-patch Size: 4463 bytes Desc: not available URL: From abokovoy at redhat.com Mon Aug 22 12:06:05 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 22 Aug 2016 15:06:05 +0300 Subject: [Freeipa-devel] [PATCHES 0038][Tests] ID views does not recognize ipakrboktoauthasdelegate attribute In-Reply-To: References: Message-ID: <20160822120605.5xfcjo3wdku4sqwa@redhat.com> On Mon, 22 Aug 2016, Lenka Doudova wrote: >Hi, > >due to implementation of [1] some ID views tests fail because they do >not recognize ipakrboktoauthasdelegate attribute. Providing fix for >this. > >Ticket: https://fedorahosted.org/freeipa/ticket/6241 ACK. -- / Alexander Bokovoy From mbabinsk at redhat.com Mon Aug 22 12:06:16 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 22 Aug 2016 14:06:16 +0200 Subject: [Freeipa-devel] [PATCH 0215-0216] Child domain fixes for AD trust In-Reply-To: <20160819082802.cfsxjpfs4vssa7yx@redhat.com> References: <20160808112722.ldzcfmfpdzzmumex@redhat.com> <36addf67-0223-b8a5-9aa5-9519f9e2c0ec@redhat.com> <20160819082802.cfsxjpfs4vssa7yx@redhat.com> Message-ID: On 08/19/2016 10:28 AM, Alexander Bokovoy wrote: > On Wed, 17 Aug 2016, Martin Babinsky wrote: >> On 08/08/2016 01:27 PM, Alexander Bokovoy wrote: >>> Hi! >>> >>> Attached two patches attempt to fix some of the issues we see with child >>> domains. >>> >>> SSSD only 'sees' users from child domains if there is an ID range for >>> each of them. However, after refactoring of trust code when external >>> trust was introduced, part of the range creation had wrong assumption >>> that if a trusted domain exists, its range also exists. This is now >>> fixed to try to create range even if the domain exists. In fact, because >>> the older code was not going to the range creation for trusted domains >>> which already existed, adding ranges was done incorrectly: ID ranges use >>> full domain name and don't need - hierarchy, but the code >>> was passing both parent and the child names. As result, an attempt to >>> create an ID range for parent was done instead of the child. Parent ID >>> range already existed so we never got to create child ID ranges at all >>> in that case. >>> >>> Finally, there is a fix in SSSD to properly generate CA paths so that >>> libkrb5 can calculate correct trust path via forest root (parent) >>> domain. While looking at that, I also decided to simplify logic in >>> ipa-kdb driver because for cross-forest trust we never can transit to >>> the child domain directly, we always have to use the forest root domain. >>> However, old code could actually set a immediate domain's parent instead >>> of the forest root for deep level trust relationship within the forest >>> we trust. As we still cannot get to second level or beyond directly or >>> via their actual parent domain, we always have to go through the forest >>> root domain. The simplified code enforces this logic. >>> >>> >>> >>> >> >> ACK, but patch 215 needs rebase for ipa-4-3 and ipa-4-2. >> > Rebased version attached. Thanks, Pushed to: master: a14ebbea895a20f5a68052e32ba65c4fd7fdf670 ipa-4-3: 775c868bacc01286eafc97e8126937d76ee53e1e ipa-4-2: ac6248430ce3358e75e6eebf01db5b9dfc55cac0 -- Martin^3 Babinsky From abokovoy at redhat.com Mon Aug 22 12:07:02 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 22 Aug 2016 15:07:02 +0300 Subject: [Freeipa-devel] [Patch 0019] Corrected minor spell check in AD Trust information doc messages In-Reply-To: References: Message-ID: <20160822120702.4wkdkm7y4xempi3z@redhat.com> On Mon, 22 Aug 2016, Abhijeet Kasurde wrote: > Hi All, > > Please find the patch attached. > > It's a minor spelling correction so, I have not created ticket for this. > ACK. -- / Alexander Bokovoy From mbasti at redhat.com Mon Aug 22 12:12:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Aug 2016 14:12:08 +0200 Subject: [Freeipa-devel] [PATCHES 0038][Tests] ID views does not recognize ipakrboktoauthasdelegate attribute In-Reply-To: <20160822120605.5xfcjo3wdku4sqwa@redhat.com> References: <20160822120605.5xfcjo3wdku4sqwa@redhat.com> Message-ID: <9d88139d-f2f3-ff6b-34ca-7ab9d8230f7b@redhat.com> On 22.08.2016 14:06, Alexander Bokovoy wrote: > On Mon, 22 Aug 2016, Lenka Doudova wrote: >> Hi, >> >> due to implementation of [1] some ID views tests fail because they do >> not recognize ipakrboktoauthasdelegate attribute. Providing fix for >> this. >> >> Ticket: https://fedorahosted.org/freeipa/ticket/6241 > ACK. > Pushed to master: 3d159c39c72ac43ae502f0cb978e534aa37f3b20 From mbasti at redhat.com Mon Aug 22 12:17:42 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Aug 2016 14:17:42 +0200 Subject: [Freeipa-devel] [Patch 0019] Corrected minor spell check in AD Trust information doc messages In-Reply-To: <20160822120702.4wkdkm7y4xempi3z@redhat.com> References: <20160822120702.4wkdkm7y4xempi3z@redhat.com> Message-ID: <973285d6-22eb-875e-0cbb-cf801788e2d9@redhat.com> On 22.08.2016 14:07, Alexander Bokovoy wrote: > On Mon, 22 Aug 2016, Abhijeet Kasurde wrote: >> Hi All, >> >> Please find the patch attached. >> >> It's a minor spelling correction so, I have not created ticket for this. >> > ACK. > Please don't update .pot files, we are doing it before release automatically using Zanata. From ldoudova at redhat.com Mon Aug 22 13:46:12 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 22 Aug 2016 15:46:12 +0200 Subject: [Freeipa-devel] [PATCH 0039][Tests] ID views tests do not recognize 'krbcanonicalname' attribute Message-ID: <0f465f11-9ac1-6a11-d000-a7d2831d77e5@redhat.com> Hi, ID views tests still do not recognize 'krbcanonicalname' attribute - fix attached. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0039-Tests-ID-views-tests-do-not-recognize-krbcanonicalna.patch Type: text/x-patch Size: 2657 bytes Desc: not available URL: From rcritten at redhat.com Mon Aug 22 14:09:08 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Aug 2016 10:09:08 -0400 Subject: [Freeipa-devel] certmonger "failed to verify signature on server response" after receiving valid certificate In-Reply-To: <2C720BBFE8885346B9A4377911BABE78868950A1@MUCS72046.corp.knorr-bremse.com> References: <2C720BBFE8885346B9A4377911BABE78868950A1@MUCS72046.corp.knorr-bremse.com> Message-ID: <57BB0784.5010903@redhat.com> Marx, Peter wrote: > I?m testing with certmonger 0.78.6 (patched for the GETCACertChain bug) > against two EJBCA servers. For verification I a use a second SCEP client > called jSCEP. > > I started certmonger in debug mode with > ?/usr/libexec/certmonger/certmonger-session -n -d 15? > > The CA file in /root/.config/certmonger/cas looks like this: > > id=Test_Sweden > > ca_aka=SCEP (certmonger 0.78.6) > > ca_is_default=0 > > ca_type=EXTERNAL > > ca_external_helper=/usr/libexec/certmonger/scep-submit -u > http://ejbca-test2.primekey.se:8080/ejbca/publicweb/apply/scep/mxratest/pkiclient.exe > -i "mx_kd3" > > ca_capabilities=POSTPKIOperation,Renewal,SHA-1 > > scep_ca_identifier=iCOM Kunde1 Schweden > > ca_encryption_cert=-----BEGIN CERTIFICATE----- > > > > -----END CERTIFICATE----- > > ca_encryption_issuer_cert=-----BEGIN CERTIFICATE----- > > > > -----END CERTIFICATE----- It looks to me that certmonger can't verify the signature of the returned PKCS#7 data. I'd double check the value of ca_encryption_issuer_cert. rob > > Issuing the request > > ?getcert request -c Test_Sweden -v -d /tmp/nssdb -g 2048 -I husky201 -p > /tmp/pwd.txt -n husky201 -L abcd -N CN='husky201' ?s? > > gives this log: > > 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for > 0x7fbe6b0c02e0. > > 2016-08-22 10:31:13 [22931] message > 0x7fbe6b0c02e0(method_call)->org.fedorahosted.certmonger:/org/fedorahosted/certmonger:org.fedorahosted.certmonger.add_request > > 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixUser serial 135 > > 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixProcessID serial 136 > > 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b0aa690. > > 2016-08-22 10:31:13 [22931] Dequeuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b0aa690. > > 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for > 0x7fbe6b0c02e0. > > 2016-08-22 10:31:13 [22931] message 0x7fbe6b0c02e0(method_return)->135->73 > > 2016-08-22 10:31:13 [22931] message 0x7fbe6b0c02e0(method_return)->136->74 > > 2016-08-22 10:31:13 [22931] User ID 0 PID 23133 called > /org/fedorahosted/certmonger:org.fedorahosted.certmonger.add_request. > > 2016-08-22 10:31:13 [23135] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23135] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23135] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:31:13 [23135] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23135] Located the key 'husky201'. > > 2016-08-22 10:31:13 [23135] Converted private key 'husky201' to public key. > > 2016-08-22 10:31:13 [23135] Key is an RSA key. > > 2016-08-22 10:31:13 [23135] Key size is 2048. > > 2016-08-22 10:31:13 [23136] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23136] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23136] Found token 'NSS Generic Crypto Services'. > > 2016-08-22 10:31:13 [23136] Cert storage slot still needs user PIN to be > set. > > 2016-08-22 10:31:13 [23136] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23136] Error locating certificate. > > 2016-08-22 10:31:13 [22931] Request7('husky201') starts in state > 'NEWLY_ADDED' > > 2016-08-22 10:31:13 [22931] Request7('husky201') taking writing lock > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEWLY_ADDED_START_READING_KEYINFO' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Started Request7('husky201'). > > 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b09b4e0. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEWLY_ADDED_READING_KEYINFO' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic > from 11. > > 2016-08-22 10:31:13 [22931] Dequeuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b09b4e0. > > 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for > 0x7fbe6b0c02e0. > > 2016-08-22 10:31:13 [22931] message > 0x7fbe6b0c02e0(method_call)->org.fedorahosted.certmonger:/org/fedorahosted/certmonger/requests/Request7:org.fedorahosted.certmonger.request.get_nickname > > 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixUser serial 140 > > 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixProcessID serial 141 > > 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b0ae0a0. > > 2016-08-22 10:31:13 [22931] Dequeuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b0ae0a0. > > 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for > 0x7fbe6b0c02e0. > > 2016-08-22 10:31:13 [22931] message 0x7fbe6b0c02e0(method_return)->140->75 > > 2016-08-22 10:31:13 [22931] message 0x7fbe6b0c02e0(method_return)->141->76 > > 2016-08-22 10:31:13 [22931] User ID 0 PID 23133 called > /org/fedorahosted/certmonger/requests/Request7:org.fedorahosted.certmonger.request.get_nickname. > > 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b09b4e0. > > 2016-08-22 10:31:13 [23137] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23137] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23137] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:31:13 [23137] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23137] Located the key 'husky201'. > > 2016-08-22 10:31:13 [23137] Converted private key 'husky201' to public key. > > 2016-08-22 10:31:13 [23137] Key is an RSA key. > > 2016-08-22 10:31:13 [23137] Key size is 2048. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEWLY_ADDED_START_READING_CERT' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEWLY_ADDED_READING_CERT' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic > from 11. > > 2016-08-22 10:31:13 [23138] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23138] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23138] Found token 'NSS Generic Crypto Services'. > > 2016-08-22 10:31:13 [23138] Cert storage slot still needs user PIN to be > set. > > 2016-08-22 10:31:13 [23138] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23138] Error locating certificate. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEWLY_ADDED_DECIDING' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') releasing writing lock > > 2016-08-22 10:31:13 [22931] Request7('husky201') has no certificate, > will attempt enrollment using already-present key > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'NEED_CSR' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'GENERATING_CSR' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic > from 11. > > 2016-08-22 10:31:13 [23139] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23139] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23139] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:31:13 [23139] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23139] Located the key 'husky201'. > > 2016-08-22 10:31:13 [23139] Converted private key 'husky201' to public key. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'HAVE_CSR' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEED_TO_SUBMIT' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'SUBMITTING' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic > from 15. > > 2016-08-22 10:31:13 [22931] Certificate submission attempt complete. > > 2016-08-22 10:31:13 [22931] Child status = 16. > > 2016-08-22 10:31:13 [22931] Child output: > > "Error reading request, expected PKCS7 data. > > " > > 2016-08-22 10:31:13 [22931] Error reading request, expected PKCS7 data. > > 2016-08-22 10:31:13 [22931] Certificate not (yet?) issued. > > 2016-08-22 10:31:13 [22931] Request7('husky201') goes to a CA over SCEP, > need to generate SCEP data. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEED_SCEP_DATA' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'GENERATING_SCEP_DATA' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic > from 11. > > 2016-08-22 10:31:13 [23141] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23141] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23141] Generating dummy key. > > 2016-08-22 10:31:13 [23141] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23141] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23141] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:31:13 [23141] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23141] Located the key 'husky201'. > > 2016-08-22 10:31:13 [23141] Converted private key 'husky201' to public key. > > 2016-08-22 10:31:13 [23141] Server does not support DES3, using DES. > > 2016-08-22 10:31:13 [23141] Server does not support better digests, > using MD5. > > 2016-08-22 10:31:13 [23141] Generating PKCSREQ pkiMessage. > > 2016-08-22 10:31:13 [23141] Setting transaction ID > "46763632748922674693649122043315271915873922247404248201497767686509312971065". > > 2016-08-22 10:31:13 [23141] Setting message type "19". > > 2016-08-22 10:31:13 [23141] Setting sender nonce. > > 2016-08-22 10:31:13 [23141] Signed data. > > 2016-08-22 10:31:13 [23141] Generating GetCertInitial pkiMessage. > > 2016-08-22 10:31:13 [23141] Setting transaction ID > "46763632748922674693649122043315271915873922247404248201497767686509312971065". > > 2016-08-22 10:31:13 [23141] Setting message type "20". > > 2016-08-22 10:31:13 [23141] Setting sender nonce. > > 2016-08-22 10:31:13 [23141] Signed data. > > 2016-08-22 10:31:13 [23141] Signing using old key. > > 2016-08-22 10:31:13 [23141] Re-signing PKCSREQ message with old key. > > 2016-08-22 10:31:13 [23141] Re-signing GetCertInitial message with old key. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'HAVE_SCEP_DATA' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEED_TO_SUBMIT' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'SUBMITTING' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on traffic > from 15. > > 2016-08-22 10:31:15 [22931] Certificate submission attempt complete. > > 2016-08-22 10:31:15 [22931] Child status = 3. > > 2016-08-22 10:31:15 [22931] Child output: > > "Error: failed to verify signature on server response. > > " > > 2016-08-22 10:31:15 [22931] Error: failed to verify signature on server > response. > > 2016-08-22 10:31:15 [22931] Certificate not (yet?) issued. > > 2016-08-22 10:31:15 [22931] Request7('husky201') moved to state > 'CA_UNREACHABLE' > > 2016-08-22 10:31:15 [22931] Will revisit Request7('husky201') in 604800 > seconds. > > I recorded the client server communication and can clearly see that the > server transmitted the certificate. > > When using jSCEP client I can successfully download certificates from > that server with e.g. > > $ openssl req -key test.key -new -days 30 -out test.pemreq -outform PEM > # end entity set to mx_pre2 > > $ java -jar target/jscepcli-1.0-SNAPSHOT-exe.jar --ca-identifier mx_kd3 > --challenge abcd --csr-file test.pemreq --dn "CN=mx_pre2" --key-file > test.key \ > > --url > http://ejbca-test2.primekey.se:8080/ejbca/publicweb/apply/scep/mxratest/pkiclient.exe > > With certmonger I can successfully get a cert using another CA with an > internal EJBCA server and this request: > > ?getcert request -c Test_Sweden -v -d /tmp/nssdb -g 2048 -I husky100 -p > /tmp/pwd.txt -n husky100 -L abcd -N CN='husky100' ?s? > > id=KBCA > > ca_aka=SCEP (certmonger 0.78.6) > > ca_is_default=0 > > ca_type=EXTERNAL > > ca_external_helper=/usr/libexec/certmonger/scep-submit -u > http://mucs70202.corp.knorr-bremse.com:8080/ejbca/publicweb/apply/scep/pkiclient.exe > -i "iCOM%20Kunde1%20Dev%20SubCA" > > ca_capabilities=POSTPKIOperation,Renewal,SHA-1 > > scep_ca_identifier=KBCA > > ca_encryption_cert=-----BEGIN CERTIFICATE----- > > > > -----END CERTIFICATE----- > > ca_encryption_issuer_cert=-----BEGIN CERTIFICATE----- > > > > -----END CERTIFICATE----- > > *ca_encryption_cert_pool*=-----BEGIN CERTIFICATE----- > > > > -----END CERTIFICATE----- > > 2016-08-22 10:05:24 [21621] User ID 0 PID 22278 called > /org/fedorahosted/certmonger:org.fedorahosted.certmonger.add_request. > > 2016-08-22 10:05:24 [22280] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:24 [22280] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:24 [22280] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:24 [22280] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:24 [22280] Error locating a key. > > 2016-08-22 10:05:24 [22281] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:24 [22281] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:24 [22281] Found token 'NSS Generic Crypto Services'. > > 2016-08-22 10:05:24 [22281] Cert storage slot still needs user PIN to be > set. > > 2016-08-22 10:05:24 [22281] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:24 [22281] Error locating certificate. > > 2016-08-22 10:05:24 [21621] Request2('husky100') starts in state > 'NEWLY_ADDED' > > 2016-08-22 10:05:24 [21621] Request2('husky100') taking writing lock > > 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state > 'NEWLY_ADDED_START_READING_KEYINFO' > > 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:24 [21621] Started Request2('husky100'). > > 2016-08-22 10:05:24 [21621] Queuing FD 8 for Read for > 0x7fdf7bf25630:0x7fdf7bf33720. > > 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state > 'NEWLY_ADDED_READING_KEYINFO' > > 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') on traffic > from 11. > > 2016-08-22 10:05:24 [21621] Dequeuing FD 8 for Read for > 0x7fdf7bf25630:0x7fdf7bf33720. > > 2016-08-22 10:05:24 [21621] Handling D-Bus traffic (Read) on FD 8 for > 0x7fdf7bf25630. > > 2016-08-22 10:05:24 [21621] message > 0x7fdf7bf25630(method_call)->org.fedorahosted.certmonger:/org/fedorahosted/certmonger/requests/Request2:org.fedorahosted.certmonger.request.get_nickname > > 2016-08-22 10:05:24 [21621] Pending GetConnectionUnixUser serial 1227 > > 2016-08-22 10:05:24 [21621] Pending GetConnectionUnixProcessID serial 1228 > > 2016-08-22 10:05:24 [21621] Queuing FD 8 for Read for > 0x7fdf7bf25630:0x7fdf7bf2bc00. > > 2016-08-22 10:05:24 [21621] Dequeuing FD 8 for Read for > 0x7fdf7bf25630:0x7fdf7bf2bc00. > > 2016-08-22 10:05:24 [21621] Handling D-Bus traffic (Read) on FD 8 for > 0x7fdf7bf25630. > > 2016-08-22 10:05:24 [21621] message 0x7fdf7bf25630(method_return)->1227->819 > > 2016-08-22 10:05:24 [21621] message 0x7fdf7bf25630(method_return)->1228->820 > > 2016-08-22 10:05:24 [21621] User ID 0 PID 22278 called > /org/fedorahosted/certmonger/requests/Request2:org.fedorahosted.certmonger.request.get_nickname. > > 2016-08-22 10:05:24 [21621] Queuing FD 8 for Read for > 0x7fdf7bf25630:0x7fdf7bf33720. > > 2016-08-22 10:05:24 [22282] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:24 [22282] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:24 [22282] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:24 [22282] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:24 [22282] Error locating a key. > > 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state > 'NEWLY_ADDED_START_READING_CERT' > > 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state > 'NEWLY_ADDED_READING_CERT' > > 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') on traffic > from 11. > > 2016-08-22 10:05:25 [22283] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22283] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22283] Found token 'NSS Generic Crypto Services'. > > 2016-08-22 10:05:25 [22283] Cert storage slot still needs user PIN to be > set. > > 2016-08-22 10:05:25 [22283] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:25 [22283] Error locating certificate. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEWLY_ADDED_DECIDING' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') releasing writing lock > > 2016-08-22 10:05:25 [21621] Request2('husky100') has no key or > certificate, will generate keys and attempt enrollment > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEED_KEY_PAIR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') taking writing lock > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'GENERATING_KEY_PAIR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic > from 11. > > 2016-08-22 10:05:25 [22284] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22284] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22284] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:25 [22284] Generating key pair. > > 2016-08-22 10:05:25 [22284] Nickname "husky100" appears to be unused. > > 2016-08-22 10:05:25 [22284] Set nickname "husky100" on private key. > > 2016-08-22 10:05:25 [21621] Request2('husky100') releasing writing lock > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'HAVE_KEY_PAIR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEED_KEYINFO' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'READING_KEYINFO' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic > from 11. > > 2016-08-22 10:05:25 [22285] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22285] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22285] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:25 [22285] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:25 [22285] Located the key 'husky100'. > > 2016-08-22 10:05:25 [22285] Converted private key 'husky100' to public key. > > 2016-08-22 10:05:25 [22285] Key is an RSA key. > > 2016-08-22 10:05:25 [22285] Key size is 2048. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'HAVE_KEYINFO' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'NEED_CSR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'GENERATING_CSR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic > from 11. > > 2016-08-22 10:05:25 [22286] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22286] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22286] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:25 [22286] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:25 [22286] Located the key 'husky100'. > > 2016-08-22 10:05:25 [22286] Converted private key 'husky100' to public key. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'HAVE_CSR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEED_TO_SUBMIT' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'SUBMITTING' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic > from 15. > > 2016-08-22 10:05:25 [21621] Certificate submission attempt complete. > > 2016-08-22 10:05:25 [21621] Child status = 16. > > 2016-08-22 10:05:25 [21621] Child output: > > "Error reading request, expected PKCS7 data. > > " > > 2016-08-22 10:05:25 [21621] Error reading request, expected PKCS7 data. > > 2016-08-22 10:05:25 [21621] Certificate not (yet?) issued. > > 2016-08-22 10:05:25 [21621] Request2('husky100') goes to a CA over SCEP, > need to generate SCEP data. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEED_SCEP_DATA' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'GENERATING_SCEP_DATA' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic > from 11. > > 2016-08-22 10:05:25 [22288] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22288] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22288] Generating dummy key. > > 2016-08-22 10:05:25 [22288] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22288] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22288] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:25 [22288] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:25 [22288] Located the key 'husky100'. > > 2016-08-22 10:05:25 [22288] Converted private key 'husky100' to public key. > > 2016-08-22 10:05:25 [22288] Server does not support DES3, using DES. > > 2016-08-22 10:05:25 [22288] Server does not support better digests, > using MD5. > > 2016-08-22 10:05:25 [22288] Generating PKCSREQ pkiMessage. > > 2016-08-22 10:05:25 [22288] Setting transaction ID > "89399340103492129363376569585892061602695437784280139265051808388486717974760". > > 2016-08-22 10:05:25 [22288] Setting message type "19". > > 2016-08-22 10:05:25 [22288] Setting sender nonce. > > 2016-08-22 10:05:25 [22288] Signed data. > > 2016-08-22 10:05:25 [22288] Generating GetCertInitial pkiMessage. > > 2016-08-22 10:05:25 [22288] Setting transaction ID > "89399340103492129363376569585892061602695437784280139265051808388486717974760". > > 2016-08-22 10:05:25 [22288] Setting message type "20". > > 2016-08-22 10:05:25 [22288] Setting sender nonce. > > 2016-08-22 10:05:25 [22288] Signed data. > > 2016-08-22 10:05:25 [22288] Signing using old key. > > 2016-08-22 10:05:25 [22288] Re-signing PKCSREQ message with old key. > > 2016-08-22 10:05:25 [22288] Re-signing GetCertInitial message with old key. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'HAVE_SCEP_DATA' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEED_TO_SUBMIT' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'SUBMITTING' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on traffic > from 15. > > 2016-08-22 10:05:26 [21621] Certificate submission attempt complete. > > 2016-08-22 10:05:26 [21621] Child status = 0. > > 2016-08-22 10:05:26 [21621] Child output: > > "-----BEGIN PKCS7----- > > MIAGCSqGSIb3DQEHA6CAMIACAQAxggFUMIIBUAIBADA4MBMxETAPBgNVBAMTCGh1 > > c2t5MTAwAiEAxaY7vcruKj5BOCTGw5wQBTpMC0GpLQ5rQJvfM6bjKOgwDQYJKoZI > > hvcNAQEBBQAEggEAF8VwCqiExnQyPQvdPV8vYFIvV0OGJ5AuyurIQQ0y3zeb6Jjc > > h4j6LilwV0BnUjdH9G2t4gGWUbbUVxciaXy0lgcZnO7C39ptc8tPfcfnD5gwRXdj > > jLjWTRa6IBhBvgZS6/tQ1uiWXygSnTVl9renZSBixKrnUSaRO5vHl4IsMWp4J8/p > > 39DY2zncvP/oq4bMKe5priZEjgbZkgFI9IuleQM80pzTHayWlChx2M5Cg5pDrBLc > > k0lZeVLQ6Vg5V3yRGSsXNrxkexYZkRFGQkZ/6gsLmj1nPPVGjhjbtoEGtQZGpXaW > > xD+nWyv2TUDge1OzIYj326scX3z3+YXcw2J23zCABgkqhkiG9w0BBwEwEQYFKw4D > > AgcECJgYnlIa2DxtoIAEggNgaTC2AhLM52T8guE2jr4YTK1UlcwDpN8yRJNRyuK7 > > vtDjx5aPx3+qTRJAOdeulV3pYK+3dpmddJoePGFpW/MaKBgAOpZVi/gk6LxnfKG4 > > l+gwPR7y3EyXXCyank553tceF08lPoPMfkRCe01le5EW2PKKH9y7JeqvVkxIjhI8 > > vaYKmARCLAtC4fXexjnjMxFKISctLTIJqqDfCn6T7h2j61jIAB4wABmTKjh1fwp5 > > +bR+enbCG33KY9taeDHvgAYl0XOi8IQ370dI57I72383RCcQdAa9qdMSnhquMyZL > > GS1zBnWrW9wMbMWkIRjR+1nGguS+6qBP4IekOuifoi/LHkSz/uOUuEi0cintRRy6 > > TsQEimydfIRfGrpcpaPCksHYUp/QZOSsQz9xAb/u6xMJMYRxKEw8q80xSniZP+dr > > HwfRThoJuxZcr3bpnRuEt2fYd1MgASeNTuZyLV4UJgdAZKAid74S0oi20OTSJyJE > > +GScqV/loZ4kJByE7fk3ZzCEWjOBhbzFzkoJ0vCxnRsq2eiyiTmTQvl4CM24q84f > > SNvUT3UE2NryGV8DSVuyUb0HX97x8Ii0l+pcciylWWy0W5qBhVlo5ns8aDfP4xqg > > blXv13hVIZPRs2KYFinK1ptOf2dBdYI8AFRx4eq85HGTd4J9yy5qIPjMfTVCNJz1 > > GLHFCIAQrClFehHvVrny0tO88B9/Xky9I6ReRPdz8kZ6GBCkTBS3I+4Km7uyo2Bd > > XE5XlBJhaVboApZIwLNaf24eqH/L9pG6O+BhzKQEFqDYmpIzWslIsBqtMPFWD5E/ > > x/v8O2Pj0b+Tmkky+VYv8gdEkOy6LPX2J4YH86PljJDEoSqhmSeeVFuGCbaRa60L > > NevoUzoQ3qCl/Brob7nDrOWeE1uJBWcDBs/CeFUvB0mfniIp0iDUOiTpWVm7drwv > > EMObPE+5SijzwFnj5HIgSpmHZUjFR9JcRfuG6E3u7BrDl1wS6U5lfb7Oqro2T6PF > > DB1+bL7NzCqF1nOYEDELOSrMxvk8/JQMxkBdrNx592FunoMEz8oAPbK5Lvt8oqE8 > > YcULZMb56Zp4S/L4P/8jV5KB9peXhxWhvU4qqXGeBBQSjggBxAURUZni5HaRrzv4 > > nUIyUuaf0fv3QY3tIi9hKaH8AAAAAAAAAAAAAA== > > -----END PKCS7----- > > " > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on traffic > from 11. > > 2016-08-22 10:05:26 [22292] Postprocessing output "-----BEGIN PKCS7----- > > MIAGCSqGSIb3DQEHA6CAMIACAQAxggFUMIIBUAIBADA4MBMxETAPBgNVBAMTCGh1 > > c2t5MTAwAiEAxaY7vcruKj5BOCTGw5wQBTpMC0GpLQ5rQJvfM6bjKOgwDQYJKoZI > > hvcNAQEBBQAEggEAF8VwCqiExnQyPQvdPV8vYFIvV0OGJ5AuyurIQQ0y3zeb6Jjc > > h4j6LilwV0BnUjdH9G2t4gGWUbbUVxciaXy0lgcZnO7C39ptc8tPfcfnD5gwRXdj > > jLjWTRa6IBhBvgZS6/tQ1uiWXygSnTVl9renZSBixKrnUSaRO5vHl4IsMWp4J8/p > > 39DY2zncvP/oq4bMKe5priZEjgbZkgFI9IuleQM80pzTHayWlChx2M5Cg5pDrBLc > > k0lZeVLQ6Vg5V3yRGSsXNrxkexYZkRFGQkZ/6gsLmj1nPPVGjhjbtoEGtQZGpXaW > > xD+nWyv2TUDge1OzIYj326scX3z3+YXcw2J23zCABgkqhkiG9w0BBwEwEQYFKw4D > > AgcECJgYnlIa2DxtoIAEggNgaTC2AhLM52T8guE2jr4YTK1UlcwDpN8yRJNRyuK7 > > vtDjx5aPx3+qTRJAOdeulV3pYK+3dpmddJoePGFpW/MaKBgAOpZVi/gk6LxnfKG4 > > l+gwPR7y3EyXXCyank553tceF08lPoPMfkRCe01le5EW2PKKH9y7JeqvVkxIjhI8 > > vaYKmARCLAtC4fXexjnjMxFKISctLTIJqqDfCn6T7h2j61jIAB4wABmTKjh1fwp5 > > +bR+enbCG33KY9taeDHvgAYl0XOi8IQ370dI57I72383RCcQdAa9qdMSnhquMyZL > > GS1zBnWrW9wMbMWkIRjR+1nGguS+6qBP4IekOuifoi/LHkSz/uOUuEi0cintRRy6 > > TsQEimydfIRfGrpcpaPCksHYUp/QZOSsQz9xAb/u6xMJMYRxKEw8q80xSniZP+dr > > HwfRThoJuxZcr3bpnRuEt2fYd1MgASeNTuZyLV4UJgdAZKAid74S0oi20OTSJyJE > > +GScqV/loZ4kJByE7fk3ZzCEWjOBhbzFzkoJ0vCxnRsq2eiyiTmTQvl4CM24q84f > > SNvUT3UE2NryGV8DSVuyUb0HX97x8Ii0l+pcciylWWy0W5qBhVlo5ns8aDfP4xqg > > blXv13hVIZPRs2KYFinK1ptOf2dBdYI8AFRx4eq85HGTd4J9yy5qIPjMfTVCNJz1 > > GLHFCIAQrClFehHvVrny0tO88B9/Xky9I6ReRPdz8kZ6GBCkTBS3I+4Km7uyo2Bd > > XE5XlBJhaVboApZIwLNaf24eqH/L9pG6O+BhzKQEFqDYmpIzWslIsBqtMPFWD5E/ > > x/v8O2Pj0b+Tmkky+VYv8gdEkOy6LPX2J4YH86PljJDEoSqhmSeeVFuGCbaRa60L > > NevoUzoQ3qCl/Brob7nDrOWeE1uJBWcDBs/CeFUvB0mfniIp0iDUOiTpWVm7drwv > > EMObPE+5SijzwFnj5HIgSpmHZUjFR9JcRfuG6E3u7BrDl1wS6U5lfb7Oqro2T6PF > > DB1+bL7NzCqF1nOYEDELOSrMxvk8/JQMxkBdrNx592FunoMEz8oAPbK5Lvt8oqE8 > > YcULZMb56Zp4S/L4P/8jV5KB9peXhxWhvU4qqXGeBBQSjggBxAURUZni5HaRrzv4 > > nUIyUuaf0fv3QY3tIi9hKaH8AAAAAAAAAAAAAA== > > -----END PKCS7----- > > ". > > 2016-08-22 10:05:26 [22292] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:26 [22292] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:26 [22292] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:26 [22292] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] error:0D0680A8:asn1 encoding > routines:ASN1_CHECK_TLEN:wrong tag > > 2016-08-22 10:05:26 [22292] error:0D07803A:asn1 encoding > routines:ASN1_ITEM_EX_D2I:nested asn1 error > > 2016-08-22 10:05:26 [22292] error:0D0680A8:asn1 encoding > routines:ASN1_CHECK_TLEN:wrong tag > > 2016-08-22 10:05:26 [22292] error:0D07803A:asn1 encoding > routines:ASN1_ITEM_EX_D2I:nested asn1 error > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Succeeded in decrypting enveloped data. > > 2016-08-22 10:05:26 [22292] Succeeded in decrypting enveloped data. > > 2016-08-22 10:05:26 [21621] Certificate submission postprocessing complete. > > 2016-08-22 10:05:26 [21621] Child status = 0. > > 2016-08-22 10:05:26 [21621] Child output: > > "{"certificate":"-----BEGIN > CERTIFICATE-----\nMIIDKjCCAhKgAwIBAgIIBVULrGtczBowDQYJKoZIhvcNAQEFBQAwIDEeMBwGA1UE\nAwwVaUNPTSBLdW5kZTEgRGV2IFN1YkNBMB4XDTE2MDgyMjA3NTUyNloXDTI2MDYw\nOTE0MjYxMVowEzERMA8GA1UEAwwIaHVza3kxMDAwggEiMA0GCSqGSIb3DQEBAQUA\nA4IBDwAwggEKAoIBAQCwj6TZXwh2TD1UJuEc/LhjgUF91BJ4OOpjt2uOyfTsGaFO\nDykz0tEWyXRk7mkHQeqC/isVD0CYz6bhks2HwwqMAIc37eaz/uEIPQu4rz59gUMl\nVkh93YOtX2JlsQ0y0QPuwIGgb3Z1NX8MbhlE0GpLrb2vY8Y0TpBjwGpbagaMRPgz\nyP2v62jau9xn+72VTjOxNImJH/8V1UTDl1gt0lR2XH5dMeo+weVW8ZUvgDykhQDj\nq4V/trRW+556owhPv2ALBpuubp99d2rfPSdWnLg7JCtpIEIGq9KcEIfV1Bq/d4zb\n3PVrb1xZIb2vCOYyijUr8OCpgMslTM1WiKdIw9GTAgMBAAGjdTBzMAwGA1UdEwEB\n/wQCMAAwHwYDVR0jBBgwFoAUp+pgIuSdJoXPRmZ6unXbKtfB2NowEwYDVR0lBAww\nCgYIKwYBBQUHAwIwHQYDVR0OBBYEFCKFlaNB18Tf7Njwy/8I1aDPge3DMA4GA1Ud\nDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAho5avfYElYPaUxr9diXxG4aA\nVijNIiGXa6FmOwmMmR2h2UUqn11doNbkR+Zv4FFjMqdlWQh4aMLhn6Z0+ahSx3NY\nHG0saJfV88loRb+zC03yOyPIjEmFo4d2Vc+CsXAQ49ElHVKjqqC3JaMrma/EfMQ2\nW6Sc8x55smgPXjPLf8VytHdjH/ZeCDFbBYqs8CS0JbjP2! UppEjwWAv4 r8QH8VWuz\n97kxRpXFVTXb/gJUCxNqJRCU1aFTfO1L6x9BzfVKJX73nyAuQmZ+090PJIFCTTx/\nexdeoX0EBPeGmV7XjAO5GqGq+P6i3oeJ/Z8Kvug0XzlUSc55SMbc+z2B07GVIA==\n-----END > CERTIFICATE-----\n","key_checked":true} > > " > > 2016-08-22 10:05:26 [21621] Issued certificate is "-----BEGIN > CERTIFICATE----- > > MIIDKjCCAhKgAwIBAgIIBVULrGtczBowDQYJKoZIhvcNAQEFBQAwIDEeMBwGA1UE > > AwwVaUNPTSBLdW5kZTEgRGV2IFN1YkNBMB4XDTE2MDgyMjA3NTUyNloXDTI2MDYw > > OTE0MjYxMVowEzERMA8GA1UEAwwIaHVza3kxMDAwggEiMA0GCSqGSIb3DQEBAQUA > > A4IBDwAwggEKAoIBAQCwj6TZXwh2TD1UJuEc/LhjgUF91BJ4OOpjt2uOyfTsGaFO > > Dykz0tEWyXRk7mkHQeqC/isVD0CYz6bhks2HwwqMAIc37eaz/uEIPQu4rz59gUMl > > Vkh93YOtX2JlsQ0y0QPuwIGgb3Z1NX8MbhlE0GpLrb2vY8Y0TpBjwGpbagaMRPgz > > yP2v62jau9xn+72VTjOxNImJH/8V1UTDl1gt0lR2XH5dMeo+weVW8ZUvgDykhQDj > > q4V/trRW+556owhPv2ALBpuubp99d2rfPSdWnLg7JCtpIEIGq9KcEIfV1Bq/d4zb > > 3PVrb1xZIb2vCOYyijUr8OCpgMslTM1WiKdIw9GTAgMBAAGjdTBzMAwGA1UdEwEB > > /wQCMAAwHwYDVR0jBBgwFoAUp+pgIuSdJoXPRmZ6unXbKtfB2NowEwYDVR0lBAww > > CgYIKwYBBQUHAwIwHQYDVR0OBBYEFCKFlaNB18Tf7Njwy/8I1aDPge3DMA4GA1Ud > > DwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAho5avfYElYPaUxr9diXxG4aA > > VijNIiGXa6FmOwmMmR2h2UUqn11doNbkR+Zv4FFjMqdlWQh4aMLhn6Z0+ahSx3NY > > HG0saJfV88loRb+zC03yOyPIjEmFo4d2Vc+CsXAQ49ElHVKjqqC3JaMrma/EfMQ2 > > W6Sc8x55smgPXjPLf8VytHdjH/ZeCDFbBYqs8CS0JbjP2UppEjwWAv4r8QH8VWuz > > 97kxRpXFVTXb/gJUCxNqJRCU1aFTfO1L6x9BzfVKJX73nyAuQmZ+090PJIFCTTx/ > > exdeoX0EBPeGmV7XjAO5GqGq+P6i3oeJ/Z8Kvug0XzlUSc55SMbc+z2B07GVIA== > > -----END CERTIFICATE----- > > ". > > 2016-08-22 10:05:26 [21621] Certificate issued (0 chain certificates, 0 > roots). > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'NEED_TO_SAVE_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') taking writing lock > > 2016-08-22 10:05:26 [21621] No hooks set for pre-save command. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'START_SAVING_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'SAVING_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on traffic > from 11. > > 2016-08-22 10:05:26 [22293] No duplicate nickname entries. > > 2016-08-22 10:05:26 [22293] No duplicate subject name entries. > > 2016-08-22 10:05:26 [22293] Imported certificate "husky100", got > nickname "husky100". > > 2016-08-22 10:05:26 [22293] Removed name from old key. > > 2016-08-22 10:05:26 [22293] Error shutting down NSS. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'SAVED_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'NEED_TO_SAVE_CA_CERTS' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'START_SAVING_CA_CERTS' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'SAVING_CA_CERTS' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on traffic > from 11. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'NEED_TO_READ_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'READING_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on traffic > from 11. > > 2016-08-22 10:05:26 [22295] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:26 [22295] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:26 [22295] Found token 'NSS Generic Crypto Services'. > > 2016-08-22 10:05:26 [22295] Cert storage slot still needs user PIN to be > set. > > 2016-08-22 10:05:26 [22295] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:26 [22295] Located the certificate "husky100". > > 2016-08-22 10:05:26 [22295] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:26 [22295] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:26 [21621] No hooks set for post-save command. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'NEED_TO_NOTIFY_ISSUED_SAVED' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') releasing writing lock > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'NOTIFYING_ISSUED_SAVED' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on traffic > from 11. > > 2016-08-22 10:05:26 [22296] 0x1d Certificate named "husky100" in token > "NSS Certificate DB" in database "/tmp/nssdb" issued by CA and saved. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'MONITORING' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') soon. > > 2016-08-22 10:05:31 [21621] Will revisit Request2('husky100') in 86400 > seconds. > > Besides this "Error reading request, expected PKCS7 data? which always > shows up and ?Error decrypting bulk key: SEC_ERROR_BAD_DATA? errors (?) > finally the cert is issued and stored into the nSS DB. > > Certificate: > > Data: > > Version: 3 (0x2) > > Serial Number: 8344117917752670949 (0x73cc4309839ebae5) > > Signature Algorithm: sha1WithRSAEncryption > > Issuer: CN=mx_kd3 > > Validity > > Not Before: Aug 19 16:03:29 2016 GMT > > Not After : Aug 2 15:23:36 2017 GMT > > Subject: CN=mx_pre2 > > Subject Public Key Info: > > Public Key Algorithm: rsaEncryption > > Public-Key: (2048 bit) > > Modulus: > > 00:89:01:fc:d4:a0:5c:df:8d:b6:f6:e3:49:8c:93: > > 77:7a:1e:26:34:4e:37:90:c3:6c:b0:e0:5d:a7:47: > > 8e:81:8f:d8:04:d5:c0:03:26:1a:a5:49:c8:82:98: > > 40:25:34:2e:43:c5:7d:cc:10:0e:b0:13:26:25:c0: > > 3d:87:15:fc:7f:90:6d:3d:2f:d6:ce:31:1f:af:38: > > 3f:8c:e9:fc:01:4c:a6:c5:3f:82:cb:c0:f8:8c:e7: > > 30:75:ba:68:b8:69:a6:6b:6c:04:a3:58:fb:b0:10: > > 94:4b:a2:f6:bd:24:f7:75:97:c0:f2:4e:ee:d9:df: > > 7b:61:8b:46:a9:d4:46:96:05:31:e5:60:87:3e:8d: > > 9b:8e:b2:f6:0f:03:1f:b7:49:1d:83:ec:9f:66:b1: > > f9:76:dd:dd:c5:b6:fa:52:5f:56:ce:2e:00:87:11: > > 90:6d:ba:c3:d7:fd:19:e0:64:c1:5d:0b:62:59:ad: > > 61:80:a7:76:d4:08:39:6b:2e:6f:05:68:c9:10:b4: > > 9f:3e:b9:d0:63:9f:7d:e1:a7:74:4f:f8:f4:17:34: > > f5:bf:ab:c6:bf:b9:48:80:59:ec:00:41:de:8b:46: > > 30:9d:8c:2b:d4:f3:2e:bd:39:e6:da:cd:d9:32:04: > > 55:04:29:26:66:0f:ac:ac:d2:bf:b1:19:56:62:0a: > > 56:69 > > Exponent: 65537 (0x10001) > > X509v3 extensions: > > X509v3 Subject Key Identifier: > > D7:06:53:64:27:62:69:3B:ED:79:B2:6A:D8:94:DD:EE:B6:9C:51:44 > > X509v3 Basic Constraints: critical > > CA:FALSE > > X509v3 Authority Key Identifier: > > keyid:8C:DB:52:66:8F:60:01:FA:58:8D:82:06:01:25:9C:2C:7D:D0:A0:14 > > X509v3 Key Usage: critical > > Digital Signature, Key Encipherment > > X509v3 Extended Key Usage: > > TLS Web Client Authentication > > Signature Algorithm: sha1WithRSAEncryption > > 45:a1:0c:9b:7b:20:31:0a:90:53:21:b8:d5:e2:05:0f:29:10: > > 77:d6:3a:44:38:9d:4a:d0:19:30:99:b9:41:0e:b1:4b:0e:c2: > > 35:36:ce:98:5f:0a:54:88:3b:91:d1:fb:df:e5:6f:57:f9:04: > > 0d:51:bf:c5:50:c3:c6:4d:88:a0:73:31:99:63:85:69:81:66: > > 93:5c:c3:bf:3f:ef:50:cc:db:de:fe:95:43:64:f0:2c:66:c1: > > f0:64:6f:8d:75:53:54:48:28:92:05:e1:21:a2:d6:fe:e3:1e: > > 5a:af:87:ba:45:06:39:47:5a:b8:df:1c:d8:cc:cf:6a:4a:ac: > > 08:92:7c:5b:08:9b:d5:0b:6d:49:33:c3:8f:a3:2c:50:4e:50: > > ae:d3:61:27:09:8c:de:c3:04:91:e0:f9:0e:aa:63:49:84:5e: > > cc:03:78:14:6e:cc:c3:5e:46:3b:56:6c:ae:20:7b:ce:51:8a: > > 78:eb:6b:4b:80:45:45:f3:3f:14:b6:d0:6a:99:d4:46:ad:d2: > > 0f:4d:99:4d:31:34:1f:4f:a3:19:92:45:8f:89:29:7e:4e:e7: > > 43:b2:15:4d:df:8a:66:70:c4:5d:b0:e3:d8:13:77:c2:51:98: > > 67:7d:b4:3c:95:71:54:05:06:1f:69:ae:fc:b1:00:b4:88:84: > > da:e0:85:ae > > subject= /CN=mx_pre2 > > issuer= /CN=mx_kd3 > > -----BEGIN PUBLIC KEY----- > > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiQH81KBc34229uNJjJN3 > > eh4mNE43kMNssOBdp0eOgY/YBNXAAyYapUnIgphAJTQuQ8V9zBAOsBMmJcA9hxX8 > > f5BtPS/WzjEfrzg/jOn8AUymxT+Cy8D4jOcwdbpouGmma2wEo1j7sBCUS6L2vST3 > > dZfA8k7u2d97YYtGqdRGlgUx5WCHPo2bjrL2DwMft0kdg+yfZrH5dt3dxbb6Ul9W > > zi4AhxGQbbrD1/0Z4GTBXQtiWa1hgKd21Ag5ay5vBWjJELSfPrnQY5994ad0T/j0 > > FzT1v6vGv7lIgFnsAEHei0YwnYwr1PMuvTnm2s3ZMgRVBCkmZg+srNK/sRlWYgpW > > aQIDAQAB > > -----END PUBLIC KEY----- > > SHA1 Fingerprint=C3:B6:32:E9:70:E8:0F:98:A5:77:8E:96:13:5B:F8:40:63:37:29:7E > > So the question is why certmonger fails to verify signature on server > response depending on which server I try. > > What is included in the checks ? hostname of clients/servers? > > How can I debug this ? I?m not an experienced C programmer and was just > able to apply that GetCACertchain fix in scep.c and build certmonger > with that. > > Peter > > > automechanika InnoTrans IAA > automechanika > 13.09.-17.09.2016 > Messe Frankfurt > Hall 3.0 > Stand G98 + E91 InnoTrans > 20.09.-23.09.2016 > Messe Berlin > Hall 1.2b > Stand 104 + 210 IAA > 22.09.-29.09.2016 > Messe Hannover > Hall 17 > Stand A30 + D131 > > > Knorr-Bremse IT-Services GmbH > Sitz: M?nchen > Gesch?ftsf?hrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald > Schneider > Registergericht M?nchen, HR B 167 268 > > This transmission is intended solely for the addressee and contains > confidential information. > If you are not the intended recipient, please immediately inform the > sender and delete the message and any attachments from your system. > Furthermore, please do not copy the message or disclose the contents to > anyone unless agreed otherwise. To the extent permitted by law we shall > in no way be liable for any damages, whatever their nature, arising out > of transmission failures, viruses, external influence, delays and the like. > > From akasurde at redhat.com Mon Aug 22 15:05:04 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Mon, 22 Aug 2016 20:35:04 +0530 Subject: [Freeipa-devel] [Patch 0019] Corrected minor spell check in AD Trust information doc messages In-Reply-To: <973285d6-22eb-875e-0cbb-cf801788e2d9@redhat.com> References: <20160822120702.4wkdkm7y4xempi3z@redhat.com> <973285d6-22eb-875e-0cbb-cf801788e2d9@redhat.com> Message-ID: <51c65aed-83d8-d8f8-5889-4a69f66f050c@redhat.com> Hi All, On 08/22/2016 05:47 PM, Martin Basti wrote: > > > On 22.08.2016 14:07, Alexander Bokovoy wrote: >> On Mon, 22 Aug 2016, Abhijeet Kasurde wrote: >>> Hi All, >>> >>> Please find the patch attached. >>> >>> It's a minor spelling correction so, I have not created ticket for >>> this. >>> >> ACK. >> > > Please don't update .pot files, we are doing it before release > automatically using Zanata. Please find updated patch. -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0019-2-Corrected-minor-spell-check-in-AD-Trust-information.patch Type: text/x-patch Size: 3905 bytes Desc: not available URL: From mbasti at redhat.com Mon Aug 22 15:15:42 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Aug 2016 17:15:42 +0200 Subject: [Freeipa-devel] [Patch 0019] Corrected minor spell check in AD Trust information doc messages In-Reply-To: <51c65aed-83d8-d8f8-5889-4a69f66f050c@redhat.com> References: <20160822120702.4wkdkm7y4xempi3z@redhat.com> <973285d6-22eb-875e-0cbb-cf801788e2d9@redhat.com> <51c65aed-83d8-d8f8-5889-4a69f66f050c@redhat.com> Message-ID: On 22.08.2016 17:05, Abhijeet Kasurde wrote: > Hi All, > > > On 08/22/2016 05:47 PM, Martin Basti wrote: >> >> >> On 22.08.2016 14:07, Alexander Bokovoy wrote: >>> On Mon, 22 Aug 2016, Abhijeet Kasurde wrote: >>>> Hi All, >>>> >>>> Please find the patch attached. >>>> >>>> It's a minor spelling correction so, I have not created ticket for >>>> this. >>>> >>> ACK. >>> >> >> Please don't update .pot files, we are doing it before release >> automatically using Zanata. > Please find updated patch. > Thanks master: * c9419411c95baa67a5bf61fad0adc239e289e4dc Corrected minor spell check in AD Trust information doc messages From mbasti at redhat.com Mon Aug 22 15:48:50 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Aug 2016 17:48:50 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add In-Reply-To: References: Message-ID: <6b7ecf18-952c-1c2e-5a35-744dc3fe434b@redhat.com> On 22.08.2016 10:22, Tomas Krizek wrote: > > Seems like a good idea, I'm attaching the updated patch. Autofill does > work when the param is required. > > > On 08/19/2016 04:19 PM, Martin Basti wrote: >> >> >> >> On 16.08.2016 17:35, Tomas Krizek wrote: >>> Hi, >>> >>> the attached patch fixes an error message when user provides an >>> empty key while adding otp token. >>> >>> https://fedorahosted.org/freeipa/ticket/6200 >>> >>> >>> >> >> I'm curious why we don't fix it here: >> >> OTPTokenKey('ipatokenotpkey?', >> cli_name='key', >> label=_('Key'), >> doc=_('Token secret (Base32; default: random)'), >> default_from=lambda: os.urandom(KEY_LENGTH), >> autofill=True, >> flags=('no_display', 'no_update', 'no_search'), >> ), >> >> >> If OTPTokenKey is mandratory, it should be required param (autofill >> should work in this case too) >> >> Martin^2 > > -- > Tomas Krizek You changed API, you must regenerate API.txt (./makeapi) and increment minor version in VERSION file Option 'ipatokenotpkey?' in command 'otptoken_add/1' in API file not found Options count in otptoken_add of 22 doesn't match expected: 23 Option ipatokenotpkey of command otptoken_add in ipalib, not in API file: OTPTokenKey('ipatokenotpkey', autofill=True, cli_name='key') Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Mon Aug 22 15:53:59 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 17:53:59 +0200 Subject: [Freeipa-devel] [freeipa PR#7] config-mod: normalize attribute names for --usersearch/--groupsearch (closed) In-Reply-To: References: Message-ID: pspacek's pull request #7: "config-mod: normalize attribute names for --usersearch/--groupsearch" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/7 From freeipa-github-notification at redhat.com Mon Aug 22 15:54:01 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 17:54:01 +0200 Subject: [Freeipa-devel] [freeipa PR#7] config-mod: normalize attribute names for --usersearch/--groupsearch (label change) In-Reply-To: References: Message-ID: pspacek's pull request #7: "config-mod: normalize attribute names for --usersearch/--groupsearch" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/7 From freeipa-github-notification at redhat.com Mon Aug 22 15:54:03 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 17:54:03 +0200 Subject: [Freeipa-devel] [freeipa PR#7] config-mod: normalize attribute names for --usersearch/--groupsearch (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request Fixed upstream master: https://fedorahosted.org/freeipa/changeset/3ac2709f4b026e7c7153777f7472c383fe99a175 See the full comment at https://github.com/freeipa/freeipa/pull/7#issuecomment-241458780 From freeipa-github-notification at redhat.com Mon Aug 22 15:59:57 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 17:59:57 +0200 Subject: [Freeipa-devel] [freeipa PR#5] migrate-ds: Mention --enable-migration in error message about migraion mode (label change) In-Reply-To: References: Message-ID: pspacek's pull request #5: "migrate-ds: Mention --enable-migration in error message about migraion mode" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/5 From freeipa-github-notification at redhat.com Mon Aug 22 15:59:58 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 17:59:58 +0200 Subject: [Freeipa-devel] [freeipa PR#5] migrate-ds: Mention --enable-migration in error message about migraion mode (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request Fixed upstream master: https://fedorahosted.org/freeipa/changeset/0f4df2f03df09ebced37ff0dd49d489782b85d73 See the full comment at https://github.com/freeipa/freeipa/pull/5#issuecomment-241460779 From freeipa-github-notification at redhat.com Mon Aug 22 16:00:00 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:00:00 +0200 Subject: [Freeipa-devel] [freeipa PR#5] migrate-ds: Mention --enable-migration in error message about migraion mode (closed) In-Reply-To: References: Message-ID: pspacek's pull request #5: "migrate-ds: Mention --enable-migration in error message about migraion mode" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/5 From freeipa-github-notification at redhat.com Mon Aug 22 16:42:14 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:42:14 +0200 Subject: [Freeipa-devel] [freeipa PR#8] add python-libsss_nss_idmap and python-sss to BuildRequires (opened) In-Reply-To: References: Message-ID: martbab's pull request #8: "add python-libsss_nss_idmap and python-sss to BuildRequires" was opened PR body: This fixes pylint failing on import errors during 'lint' phase of build. https://fedorahosted.org/freeipa/ticket/6244 See the full pull-request at https://github.com/freeipa/freeipa/pull/8 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-8.patch URL: From freeipa-github-notification at redhat.com Mon Aug 22 16:43:47 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:43:47 +0200 Subject: [Freeipa-devel] [freeipa PR#8] add python-libsss_nss_idmap and python-sss to BuildRequires (label change) In-Reply-To: References: Message-ID: martbab's pull request #8: "add python-libsss_nss_idmap and python-sss to BuildRequires" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/8 From freeipa-github-notification at redhat.com Mon Aug 22 16:44:07 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:44:07 +0200 Subject: [Freeipa-devel] [freeipa PR#8] add python-libsss_nss_idmap and python-sss to BuildRequires (comment) In-Reply-To: References: Message-ID: abbra commented on a pull request Looks good to me. See the full comment at https://github.com/freeipa/freeipa/pull/8#issuecomment-241474126 From freeipa-github-notification at redhat.com Mon Aug 22 16:44:21 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:44:21 +0200 Subject: [Freeipa-devel] [freeipa PR#9] ipa-4-3: add python-libsss_nss_idmap and python-sss to BuildRequires (opened) In-Reply-To: References: Message-ID: martbab's pull request #9: "ipa-4-3: add python-libsss_nss_idmap and python-sss to BuildRequires" was opened PR body: This fixes pylint failing on import errors during 'lint' phase of build. https://fedorahosted.org/freeipa/ticket/6244 See the full pull-request at https://github.com/freeipa/freeipa/pull/9 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-9.patch URL: From freeipa-github-notification at redhat.com Mon Aug 22 16:52:26 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:52:26 +0200 Subject: [Freeipa-devel] [freeipa PR#9] ipa-4-3: add python-libsss_nss_idmap and python-sss to BuildRequires (comment) In-Reply-To: References: Message-ID: abbra commented on a pull request The backport is OK too. See the full comment at https://github.com/freeipa/freeipa/pull/9#issuecomment-241476574 From freeipa-github-notification at redhat.com Mon Aug 22 16:52:33 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:52:33 +0200 Subject: [Freeipa-devel] [freeipa PR#9] ipa-4-3: add python-libsss_nss_idmap and python-sss to BuildRequires (label change) In-Reply-To: References: Message-ID: martbab's pull request #9: "ipa-4-3: add python-libsss_nss_idmap and python-sss to BuildRequires" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/9 From freeipa-github-notification at redhat.com Mon Aug 22 16:56:08 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:56:08 +0200 Subject: [Freeipa-devel] [freeipa PR#8] add python-libsss_nss_idmap and python-sss to BuildRequires (label change) In-Reply-To: References: Message-ID: martbab's pull request #8: "add python-libsss_nss_idmap and python-sss to BuildRequires" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/8 From freeipa-github-notification at redhat.com Mon Aug 22 16:56:10 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:56:10 +0200 Subject: [Freeipa-devel] [freeipa PR#8] add python-libsss_nss_idmap and python-sss to BuildRequires (comment) In-Reply-To: References: Message-ID: martbab commented on a pull request Fixed upstream master: https://fedorahosted.org/freeipa/changeset/a4f4cac993afa1c0bd1585d14a26d4ce1f729b95 See the full comment at https://github.com/freeipa/freeipa/pull/8#issuecomment-241477680 From freeipa-github-notification at redhat.com Mon Aug 22 16:56:11 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:56:11 +0200 Subject: [Freeipa-devel] [freeipa PR#8] add python-libsss_nss_idmap and python-sss to BuildRequires (closed) In-Reply-To: References: Message-ID: martbab's pull request #8: "add python-libsss_nss_idmap and python-sss to BuildRequires" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/8 From freeipa-github-notification at redhat.com Mon Aug 22 16:56:21 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:56:21 +0200 Subject: [Freeipa-devel] [freeipa PR#9] ipa-4-3: add python-libsss_nss_idmap and python-sss to BuildRequires (label change) In-Reply-To: References: Message-ID: martbab's pull request #9: "ipa-4-3: add python-libsss_nss_idmap and python-sss to BuildRequires" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/9 From freeipa-github-notification at redhat.com Mon Aug 22 16:56:22 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:56:22 +0200 Subject: [Freeipa-devel] [freeipa PR#9] ipa-4-3: add python-libsss_nss_idmap and python-sss to BuildRequires (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request Fixed upstream ipa-4-3: https://fedorahosted.org/freeipa/changeset/b0e43d5ec879fc56c38328cd9f01b04d8b6a870d See the full comment at https://github.com/freeipa/freeipa/pull/9#issuecomment-241477746 From freeipa-github-notification at redhat.com Mon Aug 22 16:56:23 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 18:56:23 +0200 Subject: [Freeipa-devel] [freeipa PR#9] ipa-4-3: add python-libsss_nss_idmap and python-sss to BuildRequires (closed) In-Reply-To: References: Message-ID: martbab's pull request #9: "ipa-4-3: add python-libsss_nss_idmap and python-sss to BuildRequires" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/9 From mbasti at redhat.com Mon Aug 22 17:05:38 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Aug 2016 19:05:38 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add In-Reply-To: <6b7ecf18-952c-1c2e-5a35-744dc3fe434b@redhat.com> References: <6b7ecf18-952c-1c2e-5a35-744dc3fe434b@redhat.com> Message-ID: <125c391a-36c1-5867-a395-08859093c7b5@redhat.com> On 22.08.2016 17:48, Martin Basti wrote: > > > > On 22.08.2016 10:22, Tomas Krizek wrote: >> >> Seems like a good idea, I'm attaching the updated patch. Autofill >> does work when the param is required. >> >> >> On 08/19/2016 04:19 PM, Martin Basti wrote: >>> >>> >>> >>> On 16.08.2016 17:35, Tomas Krizek wrote: >>>> Hi, >>>> >>>> the attached patch fixes an error message when user provides an >>>> empty key while adding otp token. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6200 >>>> >>>> >>>> >>> >>> I'm curious why we don't fix it here: >>> >>> OTPTokenKey('ipatokenotpkey?', >>> cli_name='key', >>> label=_('Key'), >>> doc=_('Token secret (Base32; default: random)'), >>> default_from=lambda: os.urandom(KEY_LENGTH), >>> autofill=True, >>> flags=('no_display', 'no_update', 'no_search'), >>> ), >>> >>> >>> If OTPTokenKey is mandratory, it should be required param (autofill >>> should work in this case too) >>> >>> Martin^2 >> >> -- >> Tomas Krizek > > You changed API, you must regenerate API.txt (./makeapi) and increment > minor version in VERSION file > > Option 'ipatokenotpkey?' in command 'otptoken_add/1' in API file not found > Options count in otptoken_add of 22 doesn't match expected: 23 > Option ipatokenotpkey of command otptoken_add in ipalib, not in API file: > OTPTokenKey('ipatokenotpkey', autofill=True, cli_name='key') > > Martin^2 > > [root at vm-058-107 ~]# ipa otptoken-add --key='ORSXG5DFON2AU===' Usage: ipa [global-options] otptoken-add [ID] [options] ipa: error: --key option does not take a value Well patch doesnt work for me, Honza may know if this is expected behavior of framework or just params bug Martin62 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkrizek at redhat.com Mon Aug 22 17:08:40 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Mon, 22 Aug 2016 19:08:40 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add In-Reply-To: <6b7ecf18-952c-1c2e-5a35-744dc3fe434b@redhat.com> References: <6b7ecf18-952c-1c2e-5a35-744dc3fe434b@redhat.com> Message-ID: <07734948-b57d-79a2-23cf-97bd7aacf08f@redhat.com> I've attached the updated patch. Hopefully I didn't forget anything else this time. On 08/22/2016 05:48 PM, Martin Basti wrote: > > On 22.08.2016 10:22, Tomas Krizek wrote: >> >> Seems like a good idea, I'm attaching the updated patch. Autofill >> does work when the param is required. >> >> >> On 08/19/2016 04:19 PM, Martin Basti wrote: >>> >>> >>> >>> On 16.08.2016 17:35, Tomas Krizek wrote: >>>> Hi, >>>> >>>> the attached patch fixes an error message when user provides an >>>> empty key while adding otp token. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6200 >>>> >>>> >>>> >>> >>> I'm curious why we don't fix it here: >>> >>> OTPTokenKey('ipatokenotpkey?', >>> cli_name='key', >>> label=_('Key'), >>> doc=_('Token secret (Base32; default: random)'), >>> default_from=lambda: os.urandom(KEY_LENGTH), >>> autofill=True, >>> flags=('no_display', 'no_update', 'no_search'), >>> ), >>> >>> >>> If OTPTokenKey is mandratory, it should be required param (autofill >>> should work in this case too) >>> >>> Martin^2 >> >> -- >> Tomas Krizek > > You changed API, you must regenerate API.txt (./makeapi) and increment > minor version in VERSION file > > Option 'ipatokenotpkey?' in command 'otptoken_add/1' in API file not found > Options count in otptoken_add of 22 doesn't match expected: 23 > Option ipatokenotpkey of command otptoken_add in ipalib, not in API file: > OTPTokenKey('ipatokenotpkey', autofill=True, cli_name='key') > > Martin^2 -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tkrizek-0003-3-Validate-key-in-otptoken-add.patch Type: text/x-patch Size: 2500 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Aug 22 17:14:35 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 19:14:35 +0200 Subject: [Freeipa-devel] [freeipa PR#4] Fix man page ipa-replica-manage: remove duplicate -c option from --no-lookup (label change) In-Reply-To: References: Message-ID: pspacek's pull request #4: "Fix man page ipa-replica-manage: remove duplicate -c option from --no-lookup" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/4 From freeipa-github-notification at redhat.com Mon Aug 22 17:15:49 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 19:15:49 +0200 Subject: [Freeipa-devel] [freeipa PR#4] Fix man page ipa-replica-manage: remove duplicate -c option from --no-lookup (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request Fixed upstream master: https://fedorahosted.org/freeipa/changeset/1142c3a28079316e2946ef008ad52e7e4cf89863 See the full comment at https://github.com/freeipa/freeipa/pull/4#issuecomment-241483260 From freeipa-github-notification at redhat.com Mon Aug 22 17:15:51 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 19:15:51 +0200 Subject: [Freeipa-devel] [freeipa PR#4] Fix man page ipa-replica-manage: remove duplicate -c option from --no-lookup (closed) In-Reply-To: References: Message-ID: pspacek's pull request #4: "Fix man page ipa-replica-manage: remove duplicate -c option from --no-lookup" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/4 From freeipa-github-notification at redhat.com Mon Aug 22 17:15:53 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 19:15:53 +0200 Subject: [Freeipa-devel] [freeipa PR#4] Fix man page ipa-replica-manage: remove duplicate -c option from --no-lookup (label change) In-Reply-To: References: Message-ID: pspacek's pull request #4: "Fix man page ipa-replica-manage: remove duplicate -c option from --no-lookup" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/4 From freeipa-github-notification at redhat.com Mon Aug 22 17:19:10 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Mon, 22 Aug 2016 19:19:10 +0200 Subject: [Freeipa-devel] [freeipa PR#10] Client-side CSR autogeneration (opened) In-Reply-To: References: Message-ID: LiptonB's pull request #10: "Client-side CSR autogeneration" was opened PR body: Adds a library that builds scripts that builds CSRs. Adds a CLI command, 'cert-get-requestdata', that uses this library and builds the script for a given principal. Adds rules for the caIPAserviceCert profile, as well as a new userCert profile, stored in json files in /usr/share/ipa/csr. The rule provider is a separate class so that it can be replaced easily if we ever want to move rules to the server side. See the full pull-request at https://github.com/freeipa/freeipa/pull/10 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-10.patch URL: From blipton at redhat.com Mon Aug 22 17:26:15 2016 From: blipton at redhat.com (Ben Lipton) Date: Mon, 22 Aug 2016 13:26:15 -0400 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <52e165df-fdba-1e1d-4ea0-a81678a4aa03@redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> <20160802035746.GU10771@dhcp-40-8.bne.redhat.com> <837d2da8-d6ad-912a-2b72-a39e9cb87d15@redhat.com> <6315644a-a129-cc0a-7c5e-5f76b320a771@redhat.com> <20160816181256.p26yd3lvac5miuv3@redhat.com> <52e165df-fdba-1e1d-4ea0-a81678a4aa03@redhat.com> Message-ID: <1ddc1757-5c9a-6793-a71c-670f3c3dadf1@redhat.com> On 08/16/2016 03:04 PM, Martin Kosek wrote: > On 08/16/2016 08:12 PM, Alexander Bokovoy wrote: >> On Tue, 16 Aug 2016, Ben Lipton wrote: >>> On 08/10/2016 08:52 AM, Ben Lipton wrote: >>>> The pull request at https://github.com/LiptonB/freeipa/pull/4/commits has >>>> been brought up to date (with a force push), and also includes 3 more >>>> patches, described below. >>>> >>>> The patchset is also attached. To make sure that everything applies, I just >>>> regenerated the whole set, though there may not be meaningful changes. >>>> >>> After a discussion about how to address some of the concerns that have been >>> voiced about this project, there have been some changes to the project >>> direction. So, I wanted to provide an update about what the plans are. If you >>> have objections or feel that I'm not representing it correctly, please let me >>> know. >>> >>> Since we have yet to see all the ways people will want to use this feature, >>> the immediate goal is to provide something that we can iterate on. To make >>> this easier, we will avoid storing rule data on the server or modifying the >>> server schema, as those changes would need to be supported long term/handled >>> correctly on update. I plan to approach this as follows: >>> - Separate the provider of mapping rules into a separate component from the >>> generation of a config based on those rules >>> - Build an alternative rule provider that reads local files rather than >>> querying IPA >>> - Move the implementation of CSR config formatting from the server API into a >>> library (where should this go? ipalib? ipapython?), and then provide a >>> client-side command that builds a config using the library. >> Up to you -- ipapython is traditionally used for very basic dependencies >> when nothing is configured and is used by both installers and the >> framework, ipalib -- for common code in the framework itself. >> >>> - Templates for at least two profiles ("user" profile with >>> CN=, subject and email address SAN, "service" profile >>> with CN=, subject and DNS SAN) will be provided. Users >>> will be able to build custom profiles by putting files in the appropriate >>> directories on their client machines (but we will not guarantee backward >>> compatibility for the format of these files). >>> - If we decide to move forward with storing rules on the server, the library >>> call can be referenced from the server code, using the rule provider that >>> pulls rules from the API. However, at that point we may also go in the >>> direction of making automatic cert generation fully the responsibility of >>> Dogtag, and keep the CSR-generation approach client-side only. >>> >>> Comments welcome! Unless the changes are more complex than I anticipate, I >>> hope to have a prototype of this approach for review by the end of this week. >> The summary above looks fine. > +1, this looks good to me too. Thanks Ben, good job! > > Martin it took a little longer than I expected, but the client-side implementation is now available for review at https://github.com/freeipa/freeipa/pull/10. Please take a look when you get a chance. Thanks! Ben From freeipa-github-notification at redhat.com Tue Aug 23 05:15:13 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Tue, 23 Aug 2016 07:15:13 +0200 Subject: [Freeipa-devel] [freeipa PR#11] Removed unwanted line break from RefererError Dialog message (opened) In-Reply-To: References: Message-ID: Akasurde's pull request #11: "Removed unwanted line break from RefererError Dialog message" was opened PR body: Fixes: https://fedorahosted.org/freeipa/ticket/5932 Signed-off-by: Abhijeet Kasurde See the full pull-request at https://github.com/freeipa/freeipa/pull/11 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-11.patch URL: From ftweedal at redhat.com Tue Aug 23 06:40:43 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 23 Aug 2016 16:40:43 +1000 Subject: [Freeipa-devel] [PATCH] 0100 Track lightweight CAs on replica installation Message-ID: <20160823064043.GD3877@dhcp-40-8.bne.redhat.com> Hi folks, Please review attached patch which fixes https://fedorahosted.org/freeipa/ticket/6019. Thanks, Fraser -------------- next part -------------- From 558ec02053154b472b0505e6c2279095f296cb9c Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 23 Aug 2016 16:14:30 +1000 Subject: [PATCH] Track lightweight CAs on replica installation Add Certmonger tracking requests for lightweight CAs on replica installation. As part of this change, extract most of the lightweight CA tracking code out of ipa-certupdate and into cainstance. Fixes: https://fedorahosted.org/freeipa/ticket/6019 --- ipaclient/ipa_certupdate.py | 53 +++++---------------------- ipalib/constants.py | 2 ++ ipaserver/install/cainstance.py | 80 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 91 insertions(+), 44 deletions(-) diff --git a/ipaclient/ipa_certupdate.py b/ipaclient/ipa_certupdate.py index e59047a2705eb8ccb98b5213c4c8771f55a29bc5..2b33934619aa69e941fb292660ede5f925799142 100644 --- a/ipaclient/ipa_certupdate.py +++ b/ipaclient/ipa_certupdate.py @@ -29,10 +29,7 @@ from ipaplatform import services from ipaplatform.paths import paths from ipaplatform.tasks import tasks from ipalib import api, errors, x509, certstore -from ipalib.constants import IPA_CA_CN - -IPA_CA_NICKNAME = 'caSigningCert cert-pki-ca' -RENEWAL_CA_NAME = 'dogtag-ipa-ca-renew-agent' +from ipalib.constants import IPA_CA_NICKNAME, RENEWAL_CA_NAME class CertUpdate(admintool.AdminTool): command_name = 'ipa-certupdate' @@ -85,11 +82,8 @@ class CertUpdate(admintool.AdminTool): certs = certstore.get_ca_certs(ldap, api.env.basedn, api.env.realm, ca_enabled) - # find lightweight CAs (on renewal master only) - lwcas = [] - for ca_obj in api.Command.ca_find()['result']: - if IPA_CA_CN not in ca_obj['cn']: - lwcas.append(ca_obj) + # find lightweight CAs + lwcas = api.Command.ca_find()['result'] api.Backend.rpcclient.disconnect() finally: @@ -98,8 +92,12 @@ class CertUpdate(admintool.AdminTool): server_fstore = sysrestore.FileStore(paths.SYSRESTORE) if server_fstore.has_files(): self.update_server(certs) - for entry in lwcas: - self.server_track_lightweight_ca(entry) + try: + from ipaserver.install import cainstance + cainstance.add_lightweight_ca_tracking_requests(self.log, lwcas) + except Exception as e: + self.log.exception( + "Failed to add lightweight CA tracking requests") self.update_client(certs) @@ -163,39 +161,6 @@ class CertUpdate(admintool.AdminTool): self.update_file(paths.CA_CRT, certs) - def server_track_lightweight_ca(self, entry): - nickname = "{} {}".format(IPA_CA_NICKNAME, entry['ipacaid'][0]) - criteria = { - 'cert-database': paths.PKI_TOMCAT_ALIAS_DIR, - 'cert-nickname': nickname, - 'ca-name': RENEWAL_CA_NAME, - } - request_id = certmonger.get_request_id(criteria) - if request_id is None: - try: - certmonger.dogtag_start_tracking( - secdir=paths.PKI_TOMCAT_ALIAS_DIR, - pin=certmonger.get_pin('internal'), - pinfile=None, - nickname=nickname, - ca=RENEWAL_CA_NAME, - pre_command='stop_pkicad', - post_command='renew_ca_cert "%s"' % nickname, - ) - request_id = certmonger.get_request_id(criteria) - certmonger.modify(request_id, profile='ipaCACertRenewal') - self.log.debug( - 'Lightweight CA renewal: ' - 'added tracking request for "%s"', nickname) - except RuntimeError as e: - self.log.error( - 'Lightweight CA renewal: Certmonger failed to ' - 'start tracking certificate: %s', e) - else: - self.log.debug( - 'Lightweight CA renewal: ' - 'already tracking certificate "%s"', nickname) - def update_file(self, filename, certs, mode=0o444): certs = (c[0] for c in certs if c[2] is not False) try: diff --git a/ipalib/constants.py b/ipalib/constants.py index 0574bb3aa457dd79a6d64f6b8a6b57161d32da92..d5b918c49d695c5a15bee576d88902700743e263 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -273,3 +273,5 @@ CA_SUFFIX_NAME = 'ca' PKI_GSSAPI_SERVICE_NAME = 'dogtag' IPA_CA_CN = u'ipa' IPA_CA_RECORD = "ipa-ca" +IPA_CA_NICKNAME = 'caSigningCert cert-pki-ca' +RENEWAL_CA_NAME = 'dogtag-ipa-ca-renew-agent' diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 2ec02d6628ebc9e3a9bad141ec636c84eab14cef..7c2f1e1a29a201ff53555e76a2d5aa8408037eee 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1379,6 +1379,9 @@ class CAInstance(DogtagInstance): self.step("enabling CA instance", self.__enable_instance) + self.step("configuring certmonger renewal for lightweight CAs", + self.__add_lightweight_ca_tracking_requests) + self.start_creation(runtime=210) def setup_lightweight_ca_key_retrieval(self): @@ -1444,6 +1447,36 @@ class CAInstance(DogtagInstance): os.chmod(keyfile, 0o600) os.chown(keyfile, pent.pw_uid, pent.pw_gid) + def __add_lightweight_ca_tracking_requests(self): + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) + is_already_connected = conn.isconnected() + + if not is_already_connected: + try: + conn.connect(autobind=True) + except errors.PublicError as e: + self.log.error( + "Cannot connect to LDAP to add " + "lightweight CA tracking requests: %s", + e + ) + return + + try: + lwcas = conn.get_entries( + base_dn=ipautil.realm_to_suffix(api.env.realm), + filter='(objectclass=ipaca)', + attrs_list=['cn', 'ipacaid'], + ) + add_lightweight_ca_tracking_requests(self.log, lwcas) + except errors.NotFound: + pass # shouldn't happen, but don't fail if it does + finally: + if not is_already_connected: + conn.disconnect() + def replica_ca_install_check(config): if not config.setup_ca: @@ -2066,6 +2099,53 @@ def ensure_default_caacl(): api.Backend.ldap2.disconnect() +def add_lightweight_ca_tracking_requests(logger, lwcas): + """Add tracking requests for the given lightweight CAs. + + The entries must have the 'cn' and 'ipacaid' attributes. + + The IPA CA, if present, is skipped. + + """ + for entry in lwcas: + if ipalib.constants.IPA_CA_CN in entry['cn']: + continue + + nickname = "{} {}".format( + ipalib.constants.IPA_CA_NICKNAME, + entry['ipacaid'][0]) + criteria = { + 'cert-database': paths.PKI_TOMCAT_ALIAS_DIR, + 'cert-nickname': nickname, + 'ca-name': ipalib.constants.RENEWAL_CA_NAME, + } + request_id = certmonger.get_request_id(criteria) + if request_id is None: + try: + certmonger.dogtag_start_tracking( + secdir=paths.PKI_TOMCAT_ALIAS_DIR, + pin=certmonger.get_pin('internal'), + pinfile=None, + nickname=nickname, + ca=ipalib.constants.RENEWAL_CA_NAME, + pre_command='stop_pkicad', + post_command='renew_ca_cert "%s"' % nickname, + ) + request_id = certmonger.get_request_id(criteria) + certmonger.modify(request_id, profile='ipaCACertRenewal') + logger.debug( + 'Lightweight CA renewal: ' + 'added tracking request for "%s"', nickname) + except RuntimeError as e: + logger.error( + 'Lightweight CA renewal: Certmonger failed to ' + 'start tracking certificate: %s', e) + else: + logger.debug( + 'Lightweight CA renewal: ' + 'already tracking certificate "%s"', nickname) + + def update_ipa_conf(): """ Update IPA configuration file to ensure that RA plugins are enabled and -- 2.5.5 From freeipa-github-notification at redhat.com Tue Aug 23 07:27:53 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Tue, 23 Aug 2016 09:27:53 +0200 Subject: [Freeipa-devel] [freeipa PR#11] Removed unwanted line break from RefererError Dialog message (label change) In-Reply-To: References: Message-ID: Akasurde's pull request #11: "Removed unwanted line break from RefererError Dialog message" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/11 From freeipa-github-notification at redhat.com Tue Aug 23 07:44:48 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Tue, 23 Aug 2016 09:44:48 +0200 Subject: [Freeipa-devel] [freeipa PR#12] Tests: Duplicate declaration on variables in ID views tests (opened) In-Reply-To: References: Message-ID: mirielka's pull request #12: "Tests: Duplicate declaration on variables in ID views tests" was opened PR body: In ipatests/test_xmlrpc/test_idviews_plugin several variables are declared twice, while never using the first declaration. The duplicate declaration is hereby removed. https://fedorahosted.org/freeipa/ticket/6246 See the full pull-request at https://github.com/freeipa/freeipa/pull/12 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-12.patch URL: From freeipa-github-notification at redhat.com Tue Aug 23 07:46:37 2016 From: freeipa-github-notification at redhat.com (freeipa-github-notification at redhat.com) Date: Tue, 23 Aug 2016 09:46:37 +0200 Subject: [Freeipa-devel] [freeipa PR#12] Tests: Duplicate declaration on variables in ID views tests (label change) In-Reply-To: References: Message-ID: mirielka's pull request #12: "Tests: Duplicate declaration on variables in ID views tests" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/12 From jcholast at redhat.com Tue Aug 23 07:54:46 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 23 Aug 2016 09:54:46 +0200 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <57f0be1e-2915-fa33-d579-f173f1f5d019@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <20160725111123.qthtarfgcsfbdnzk@redhat.com> <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> <57f0be1e-2915-fa33-d579-f173f1f5d019@redhat.com> Message-ID: <4f2f65ed-e525-1f04-f19b-c8a00b23001f@redhat.com> On 8.8.2016 22:23, Ben Lipton wrote: > On 07/25/2016 07:45 AM, Jan Cholasta wrote: >> On 25.7.2016 13:11, Alexander Bokovoy wrote: >>> On Mon, 25 Jul 2016, Jan Cholasta wrote: >>>> On 20.7.2016 16:05, Ben Lipton wrote: >>>>> Hi, >>>>> >>>>> Thanks very much for the feedback! Some responses below; I hope you'll >>>>> let me know what you think of my reasoning. >>>>> >>>>> >>>>> On 07/20/2016 04:20 AM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 17.6.2016 00:06, Ben Lipton wrote: >>>>>>> On 06/14/2016 08:27 AM, Ben Lipton wrote: >>>>>>>> Hello all, >>>>>>>> >>>>>>>> I have written up a design proposal for making certificate requests >>>>>>>> easier to generate when using alternate certificate profiles: >>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The use case for this is described in >>>>>>>> https://fedorahosted.org/freeipa/ticket/4899. I will be working on >>>>>>>> implementing this design over the next couple of months. If you >>>>>>>> have >>>>>>>> the time and interest, please take a look and share any comments or >>>>>>>> concerns that you have. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Ben >>>>>>>> >>>>>>> Just a quick update to say that I've created a new document that >>>>>>> covers >>>>>>> the proposed schema additions in a more descriptive way (with >>>>>>> diagrams!) >>>>>>> I'm very new to developing with LDAP, so some more experienced >>>>>>> eyes on >>>>>>> the proposal would be very helpful, even if you don't have time to >>>>>>> absorb the full design. Please take a look at >>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >>>>>>> >>>>>>> >>>>>>> >>>>>>> if you have a chance. >>>>>> >>>>>> I finally had a chance to take a look at this, here are some >>>>>> comments: >>>>>> >>>>>> 1) I don't like how transformation rules are tied to a particular >>>>>> helper and have to be duplicated for each of them. They should be >>>>>> generic and work with any helper, as helpers are just an >>>>>> implementation detail and their resulting data is the same. >>>>>> >>>>>> In fact, I think I would prefer if the CSR was generated using >>>>>> python-cryptography's CertificateSigningRequestBuilder [1] rather >>>>>> than >>>>>> openssl or certutil or any other command line tool. >>>>>> >>>>> There are lots of tools that users might want to use to manage their >>>>> private keys, so I don't know if we can assume that whatever >>>>> library we >>>>> prefer will actually be able to access the private key to sign a CSR, >>>>> which is why I thought it would be useful to support more than one. >>>> >>>> python-cryptography has the notion of backends, which allow it to >>>> support multiple crypto implementations. Upstream it currently >>>> supports only OpenSSL [2], but some work has been done on PKCS#11 >>>> backend [3], which provides support for HSMs and soft-tokens (like NSS >>>> databases). >>>> >>>> Alternatively, for NSS databases (and other "simple" cases), you can >>>> generate the private key with python-cryptography using the default >>>> backend, export it to a file and import the file to the target >>>> database, so you don't actually need the PKCS#11 backend for them. >>>> >>>> So, the only thing that's currently lacking is HSM support, but given >>>> that we don't support HSMs in IPA nor in certmonger, I don't think >>>> it's an issue for now. >>>> >>>>> The >>>>> purpose of the mapping rule is to tie together the transformation >>>>> rules >>>>> that produce the same data into an object that's >>>>> implementation-agnostic, so that profiles referencing those rules are >>>>> automatically compatible with all the helper options. >>>> >>>> They are implementation-agnostic, as long as you consider `openssl` >>>> and `certutil` the only implementations :-) But I don't think this >>>> solution scales well to other possible implementations. >>>> >>>> Anyway, my main grudge is that the transformation rules shouldn't >>>> really be stored on and processed by the server. The server should >>>> know the *what* (mapping rules), but not the *how* (transformation >>>> rules). The *how* is an implementation detail and does not change in >>>> time, so there's no benefit in handling it on the server. It should be >>>> handled exclusively on the client, which I believe would also make the >>>> whole thing more robust (it would not be possible for a bug on the >>>> server to break all the clients). >>> This is a good point. However, for the scope of Ben's project can we >>> limit it by openssl and certutil support? Otherwise Ben wouldn't be able >>> to complete the project in time. >> >> I'm fine with that, but I don't think it's up to me :-) >> >>> >>>>> This is turning out to be a common (and, I think, reasonable) reaction >>>>> to the proposal. It is rather complex, and I worry that it will be >>>>> difficult to configure. On the other hand, there is some hidden >>>>> complexity to enabling a simpler config format, as well. One of the >>>>> goals of the project as it was presented to me was to allow the >>>>> creation >>>>> of profiles that add certificate extensions *that FreeIPA doesn't yet >>>>> know about*. With the current proposal, one only has to add a rule >>>>> generating text that the helper will understand. >>>> >>>> ... which will be possible only as long as the helper understands the >>>> extension. Which it might not, thus the current proposal works only >>>> for *some* extensions that FreeIPA doesn't yet support. >>> We can go ad infinitum here but with any helper implementation, be it >>> python-cryptography or anything else, you will need to have a support >>> there as well. >> >> My point was that the current proposal is not any better than my >> proposal in this regard, as neither of them allows one to use an >> arbitrary extension. >> >>> The idea with unknown extensions was to allow mapping >>> their acceptance to a specific relationship between IPA objects >>> (optionally) and an input from the CSR. A simplest example would be an >>> identity rule that would copy an ASN.1 encoded content from the CSR to >>> the certificate. >>> >>> That's on the mapping side, not on the CSR generation side, but it would >>> go similarly for the CSR if you would be able to enter unknown but >>> otherwise correct ASN.1 stream. There is no difference at which helper >>> type we are talking about because all of them support inserting ASN.1 >>> content. >>> >>>>> With your suggestion, >>>>> if there's a mapping between "san_directoryname" and the corresponding >>>>> API calls or configuration lines, we need some way for users to >>>>> augment >>>>> that mapping without changing the code. If there's no mapping, and >>>>> it's >>>>> just done with text processing, we need enough in the config format to >>>>> be able to generate fairly complex structures: >>>>> >>>>> builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>>>> builder = >>>>> builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>>>> >>>>> >>>>> x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False) >>>>> >>>>> and we need to do it without it being equivalent to calling eval() on >>>>> the config attributes. I'm not sure how to achieve this (is it safe to >>>>> call getattr(x509, extensiontype)(value) where extensiontype and value >>>>> are user-specified?) and it definitely would have to be tied to a >>>>> particular library/tool. >>>> >>>> As I pointed out above, this needs to be figured out for the generic >>>> case for both the current proposal and my suggestion. > I have a proof of concept[1] for using openssl-based rules to add a > subject alt name extension without using openssl's knowledge of that > extension. It's not extremely pretty, and it took some trial and error, > but no code changes. So, I think this actually is a difference between > the two proposals. With the obvious catch being that it works only with OpenSSL, which might not work for everyone, e.g. when using HSMs or SmartCards, due to a limited PKCS#11 support in OpenSSL. > > Next we have the easy case, extensions that we as FreeIPA developers > know are important and build support for. For these, the two proposals > work equivalently well, but yours is simpler to configure because the > knowledge of how to make a san_rfc822name is built into the library > instead of being stored on the server as a set of rules. > > Finally, we have the case of extensions that are known to the helper, > but not to FreeIPA. In the existing proposal, new rules can be written > to support these extensions under a particular helper. Further, those > rules can be used by reference in many profiles, reducing duplication of > effort/data/errors. > > As I understand it, the main objections in this thread are that > transformation rules are implementation (i.e. helper) specific data > stored in the IPA server, and that the system has several levels of > schema when it could just embed rules in the profile. But without > helper-specific rules, administrators could not take advantage of the > additional extensions supported by the helper they are using. There is *no* advantage in forcing the user to choose between helpers which differ only in the set of limitations on the CSR they are able to produce. The user should specify a) where the private key is located and b) what profile to use, and that's it, it should just work. > And > without the separation of profiles from mapping rules in the schema, > rules would need to be copy+pasted among profiles, and grouping rules > with the same effect under different helpers would be much uglier. We > can and should discuss whether these are the right tradeoffs, but this > is where those decisions came from. > >>>> >>>> OTOH, I think we could use GSER encoding of the extension value: >>>> >>>> { rfc822Name:"user at example.com", >>>> directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } >>> GSER is not really used widely and does not have standardized encoding >>> rules beyond its own definition. If you want to allow transformation >>> rules in GSER that mention existing content in IPA objects, you would >>> need to deal with templating anyway. At this point it becomes irrelevant >>> what you are templating, though. >> >> True, but the goal here is not to avoid templating, but rather to >> avoid implementation-specific bits on the server, and GSER is the only >> thing that is textual, implementation-neutral and, as a bonus, >> standardized. >> > As I said elsewhere, we could use GSER as a textual output format > instead of openssl or certutil, but it still needs its own "helper" to > build the CSR, and unlike the other options, it seems like we might need > to implement that helper. I'm not sure it's fair to call it > implementation-neutral if no implementation exists yet :) Right. Like I said, using GSER was just a quick idea off the top of my head. I would actually rather use some sort of data structure templating rather than textual templating on top of any kind of textual representation of said data structures. I don't know if there is such a thing, though. > But, with > sufficient time to do so, I would agree that building GSER support into > python-cryptography or some other library could be an elegant way to > abstract away the helper utilities. I think even in this environment the > schema/syntax simplification you proposed would be problematic, as some > of the reasons discussed above would still hold. > > [1] > [root at vm-058-019 freeipa]# ipa certtransformationrule-show GenericSAN > GenericSANOpenssl > Certificate Transformation Rule ID: GenericSANOpenssl > String defining the transformation: {% set extension = true > %}2.5.29.17=ASN1:SEQUENCE:{% call openssl.section() %}{{ > datarules|join(n) }}{% endcall %} > Name of CSR generation helper: openssl > [root at vm-058-019 freeipa]# ipa certtransformationrule-show GenericDNS > GenericDNSOpenssl > Certificate Transformation Rule ID: GenericDNSOpenssl > String defining the transformation: dns=IMPLICIT:2,IA5STRING:{{ > ipa.datafield(subject.krbprincipalname.0|safe_attr("hostname")) }} > Name of CSR generation helper: openssl -- Jan Cholasta From mbasti at redhat.com Tue Aug 23 09:39:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Aug 2016 11:39:36 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add In-Reply-To: <125c391a-36c1-5867-a395-08859093c7b5@redhat.com> References: <6b7ecf18-952c-1c2e-5a35-744dc3fe434b@redhat.com> <125c391a-36c1-5867-a395-08859093c7b5@redhat.com> Message-ID: <475bce48-0786-2ad1-8c57-ad10f1b09d5a@redhat.com> On 22.08.2016 19:05, Martin Basti wrote: > > > > On 22.08.2016 17:48, Martin Basti wrote: >> >> >> >> On 22.08.2016 10:22, Tomas Krizek wrote: >>> >>> Seems like a good idea, I'm attaching the updated patch. Autofill >>> does work when the param is required. >>> >>> >>> On 08/19/2016 04:19 PM, Martin Basti wrote: >>>> >>>> >>>> >>>> On 16.08.2016 17:35, Tomas Krizek wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes an error message when user provides an >>>>> empty key while adding otp token. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6200 >>>>> >>>>> >>>>> >>>> >>>> I'm curious why we don't fix it here: >>>> >>>> OTPTokenKey('ipatokenotpkey?', >>>> cli_name='key', >>>> label=_('Key'), >>>> doc=_('Token secret (Base32; default: random)'), >>>> default_from=lambda: os.urandom(KEY_LENGTH), >>>> autofill=True, >>>> flags=('no_display', 'no_update', 'no_search'), >>>> ), >>>> >>>> >>>> If OTPTokenKey is mandratory, it should be required param (autofill >>>> should work in this case too) >>>> >>>> Martin^2 >>> >>> -- >>> Tomas Krizek >> >> You changed API, you must regenerate API.txt (./makeapi) and >> increment minor version in VERSION file >> >> Option 'ipatokenotpkey?' in command 'otptoken_add/1' in API file not >> found >> Options count in otptoken_add of 22 doesn't match expected: 23 >> Option ipatokenotpkey of command otptoken_add in ipalib, not in API file: >> OTPTokenKey('ipatokenotpkey', autofill=True, cli_name='key') >> >> Martin^2 >> >> > > [root at vm-058-107 ~]# ipa otptoken-add --key='ORSXG5DFON2AU===' > Usage: ipa [global-options] otptoken-add [ID] [options] > > ipa: error: --key option does not take a value > > > Well patch doesnt work for me, Honza may know if this is expected > behavior of framework or just params bug > > Martin62 > > My, bad this is expected. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue Aug 23 09:46:57 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 23 Aug 2016 19:46:57 +1000 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> <20160815071516.GL23927@dhcp-40-8.bne.redhat.com> <20160819111122.GP3877@dhcp-40-8.bne.redhat.com> Message-ID: <20160823094657.GE3877@dhcp-40-8.bne.redhat.com> Thanks for review; rebased and updated patch attached. Only 0090 has substantive changes. Cheers, Fraser On Mon, Aug 22, 2016 at 09:22:08AM +0200, Jan Cholasta wrote: > On 19.8.2016 13:11, Fraser Tweedale wrote: > > Bump for review. > > > > On Mon, Aug 15, 2016 at 05:15:16PM +1000, Fraser Tweedale wrote: > > > Thanks for reviews. Rebased and updated patches attached (and one > > > new patch). No substantive changes to 92..94. Patch order is: > > > > > > 92-2, 93-2, 94-2, 98, 90-3 > > > > > > Other comments inline. > > > > > > Thanks, > > > Fraser > > > > > > On Fri, Aug 12, 2016 at 11:33:28AM +0200, Jan Cholasta wrote: > > > > Patch 0092: ACK > > > > > > > > Patch 0093: ACK > > > > > > > > Patch 0094: ACK > > Please fix this PEP8 issue before pushing: > > ./ipaserver/plugins/cert.py:597:17: W503 line break before binary operator > > > Patch 0098: ACK > > > > > > > > > Patch 0090: > > > > > > > > 1) Generic otherNames (san_other) do not work correctly. The OID is not > > > > included in the value and names with complex type other than > > > > KerberosPrincipal are not parsed correctly. The value should include the OID > > > > and DER blob of the name. > > > > > > > Updated to use "OID:b64(DER)" as the attribute value. > > OK. > > > > > > > > 2) With --all, san_other should be included in the result for all > > > > otherNames, even the known ones, to provide (limited) forward compatibility. > > > > > > > Done; when --all given, known otherName kinds are included in > > > 'san_other' attribute in addition to their own attribute. > > OK. > > > > > > > > 3) Do we have to support *all* the name types? I mean we could, for the sake > > > > of completeness, but it might be easier to just keep the few ones we > > > > actually care about (email, DNS name, principal name, UPN and directory name > > > > in your patch 0095). > > > > > > > Yeah, why not support them all? See also Petr's comments in other > > > branch of thread. > > Works for me, but see Luk??'s reply, I think he has a point. Maybe we can > make a compromise and show only supported name types by default and > everything with --all? > Now only showing DNSName, RFC822Name, DirectoryName, UPN and KRBPrincipalName unless --all is given. > > > > > > > 4) > > > > > > > > + obj.setdefault(attr_name, []).append(unicode(name)) > > > > > > > > The value should not (always) be unicode, but of the type declared by the > > > > param (unicode or ipapython.kerberos.Principal or > > > > ipapython.dnsutil.DNSName). > > > > > > > I now pass the value to the constructor of whatever type the > > > parameter uses: > > > > > > attr_value = self.params[attr_name].type(name_formatted) > > > obj.setdefault(attr_name, []).append(attr_value) > > OK. > > > 5) san_directoryname should be a DNParam rather than Str. > Fixed, thanks. > > 6) Could we use "Subject " instead of "Subject Alternative Name > ()" for labels? Or something else which is shorter and has the > name type more "visible" than the current form. > No worries. > > 7) The patch needs a rebase. > > > -- > Jan Cholasta -------------- next part -------------- From 9dbe4c3cebb1279aefefe3dae9f3da2232d9c12f Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 21 Jul 2016 16:27:49 +1000 Subject: [PATCH 92/94] Move GeneralName parsing code to ipalib.x509 GeneralName parsing code is primarily relevant to X.509. An upcoming change will add SAN parsing to the cert-show command, so first move the GeneralName parsing code from ipalib.pkcs10 to ipalib.x509. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/pkcs10.py | 93 ++----------------------------------- ipalib/x509.py | 114 +++++++++++++++++++++++++++++++++++++++++++++- ipaserver/plugins/cert.py | 8 ++-- 3 files changed, 120 insertions(+), 95 deletions(-) diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py index e340c1a2005ad781542a32a0a76753e80364dacf..158ebb3a25be2bd292f3883545fe8afe49b7be8c 100644 --- a/ipalib/pkcs10.py +++ b/ipalib/pkcs10.py @@ -22,9 +22,10 @@ from __future__ import print_function import sys import base64 import nss.nss as nss -from pyasn1.type import univ, char, namedtype, tag +from pyasn1.type import univ, namedtype, tag from pyasn1.codec.der import decoder import six +from ipalib import x509 if six.PY3: unicode = str @@ -32,11 +33,6 @@ if six.PY3: PEM = 0 DER = 1 -SAN_DNSNAME = 'DNS name' -SAN_RFC822NAME = 'RFC822 Name' -SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' -SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' - def get_subject(csr, datatype=PEM): """ Given a CSR return the subject value. @@ -72,78 +68,6 @@ def get_extensions(csr, datatype=PEM): return tuple(get_prefixed_oid_str(ext)[4:] for ext in request.extensions) -class _PrincipalName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('name-type', univ.Integer().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('name-string', univ.SequenceOf(char.GeneralString()).subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - ) - -class _KRB5PrincipalName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('realm', char.GeneralString().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('principalName', _PrincipalName().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - ) - -def _decode_krb5principalname(data): - principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0] - realm = (str(principal['realm']).replace('\\', '\\\\') - .replace('@', '\\@')) - name = principal['principalName']['name-string'] - name = '/'.join(str(n).replace('\\', '\\\\') - .replace('/', '\\/') - .replace('@', '\\@') for n in name) - name = '%s@%s' % (name, realm) - return name - -class _AnotherName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('type-id', univ.ObjectIdentifier()), - namedtype.NamedType('value', univ.Any().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - ) - -class _GeneralName(univ.Choice): - componentType = namedtype.NamedTypes( - namedtype.NamedType('otherName', _AnotherName().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('rfc822Name', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - namedtype.NamedType('dNSName', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2)) - ), - namedtype.NamedType('x400Address', univ.Sequence().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) - ), - namedtype.NamedType('directoryName', univ.Choice().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) - ), - namedtype.NamedType('ediPartyName', univ.Sequence().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 5)) - ), - namedtype.NamedType('uniformResourceIdentifier', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 6)) - ), - namedtype.NamedType('iPAddress', univ.OctetString().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 7)) - ), - namedtype.NamedType('registeredID', univ.ObjectIdentifier().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 8)) - ), - ) - -class _SubjectAltName(univ.SequenceOf): - componentType = _GeneralName() def get_subjectaltname(csr, datatype=PEM): """ @@ -159,19 +83,8 @@ def get_subjectaltname(csr, datatype=PEM): return None del request - nss_names = nss.x509_alt_name(extension.value, nss.AsObject) - asn1_names = decoder.decode(extension.value.data, - asn1Spec=_SubjectAltName())[0] - names = [] - for nss_name, asn1_name in zip(nss_names, asn1_names): - name_type = nss_name.type_string - if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: - name = _decode_krb5principalname(asn1_name['otherName']['value']) - else: - name = nss_name.name - names.append((name_type, name)) + return x509.decode_generalnames(extension.value) - return tuple(names) # Unfortunately, NSS can only parse the extension request attribute, so # we have to parse friendly name ourselves (see RFC 2986) diff --git a/ipalib/x509.py b/ipalib/x509.py index 82194922d151a1b0f2df03df3578ad45b43b71c9..15168de08240a84794efef409d022eaa983291c9 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -40,7 +40,7 @@ import re import nss.nss as nss from nss.error import NSPRError -from pyasn1.type import univ, namedtype, tag +from pyasn1.type import univ, char, namedtype, tag from pyasn1.codec.der import decoder, encoder import six @@ -63,6 +63,11 @@ EKU_EMAIL_PROTECTION = '1.3.6.1.5.5.7.3.4' EKU_ANY = '2.5.29.37.0' EKU_PLACEHOLDER = '1.3.6.1.4.1.3319.6.10.16' +SAN_DNSNAME = 'DNS name' +SAN_RFC822NAME = 'RFC822 Name' +SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' +SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' + _subject_base = None def subject_base(): @@ -374,6 +379,113 @@ def encode_ext_key_usage(ext_key_usage): eku = encoder.encode(eku) return _encode_extension('2.5.29.37', EKU_ANY not in ext_key_usage, eku) + +class _AnotherName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('type-id', univ.ObjectIdentifier()), + namedtype.NamedType('value', univ.Any().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + ) + + +class _GeneralName(univ.Choice): + componentType = namedtype.NamedTypes( + namedtype.NamedType('otherName', _AnotherName().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('rfc822Name', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + namedtype.NamedType('dNSName', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2)) + ), + namedtype.NamedType('x400Address', univ.Sequence().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) + ), + namedtype.NamedType('directoryName', univ.Choice().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) + ), + namedtype.NamedType('ediPartyName', univ.Sequence().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 5)) + ), + namedtype.NamedType('uniformResourceIdentifier', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 6)) + ), + namedtype.NamedType('iPAddress', univ.OctetString().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 7)) + ), + namedtype.NamedType('registeredID', univ.ObjectIdentifier().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 8)) + ), + ) + + +class _SubjectAltName(univ.SequenceOf): + componentType = _GeneralName() + + +class _PrincipalName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('name-type', univ.Integer().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('name-string', univ.SequenceOf(char.GeneralString()).subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + ) + + +class _KRB5PrincipalName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('realm', char.GeneralString().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('principalName', _PrincipalName().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + ) + + +def _decode_krb5principalname(data): + principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0] + realm = (str(principal['realm']).replace('\\', '\\\\') + .replace('@', '\\@')) + name = principal['principalName']['name-string'] + name = '/'.join(str(n).replace('\\', '\\\\') + .replace('/', '\\/') + .replace('@', '\\@') for n in name) + name = '%s@%s' % (name, realm) + return name + + +def decode_generalnames(secitem): + """ + Decode a GeneralNames object (this the data for the Subject + Alt Name and Issuer Alt Name extensions, among others). + + ``secitem`` + The input is the DER-encoded extension data, without the + OCTET STRING header, as an nss SecItem object. + + Return a list of tuples of name types (as string, suitable for + presentation) and names (as string, suitable for presentation). + + """ + nss_names = nss.x509_alt_name(secitem, repr_kind=nss.AsObject) + asn1_names = decoder.decode(secitem.data, asn1Spec=_SubjectAltName())[0] + names = [] + for nss_name, asn1_name in zip(nss_names, asn1_names): + name_type = nss_name.type_string + if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: + name = _decode_krb5principalname(asn1_name['otherName']['value']) + else: + name = nss_name.name + names.append((name_type, name)) + + return names + + if __name__ == '__main__': # this can be run with: # python ipalib/x509.py < /etc/ipa/ca.crt diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 6dd9f6ffcdcd9d051d50d912996fea2104d71dff..c25965080e40dcbcaa21ab140509eaf2e29d7c61 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -560,7 +560,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): # Validate the subject alt name, if any for name_type, name in subjectaltname: - if name_type == pkcs10.SAN_DNSNAME: + if name_type == x509.SAN_DNSNAME: name = unicode(name) alt_principal_obj = None alt_principal_string = unicode(principal) @@ -591,13 +591,13 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "with subject alt name '%s'.") % name) if alt_principal_string is not None and not bypass_caacl: caacl_check(principal_type, principal, ca, profile_id) - elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, - pkcs10.SAN_OTHERNAME_UPN): + elif name_type in (x509.SAN_OTHERNAME_KRB5PRINCIPALNAME, + x509.SAN_OTHERNAME_UPN): if name != principal_string: raise errors.ACIError( info=_("Principal '%s' in subject alt name does not " "match requested principal") % name) - elif name_type == pkcs10.SAN_RFC822NAME: + elif name_type == x509.SAN_RFC822NAME: if principal_type == USER: if name not in principal_obj.get('mail', []): raise errors.ValidationError( -- 2.5.5 -------------- next part -------------- From 4c72105829ffa02bde5e11669440ca2e095c35e9 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 22 Jul 2016 12:05:13 +1000 Subject: [PATCH 93/94] x509: fix SAN directoryName parsing The subjectAltName extension parsing code in ipalib.x509 fails on directoryName values because the Choice structure is not endowed with an inner type. Implement the Name structure, whose inner type is a CHOICE { SEQUENCE OF RelativeDistinguishedName }, to resolve. Note that the structure still does not get fully parsed; only enough to recognise the SequenceOf tag and not fail. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/x509.py | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/ipalib/x509.py b/ipalib/x509.py index 15168de08240a84794efef409d022eaa983291c9..2dc67441c92686826dd24f00a5ad30566cd032da 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -196,6 +196,12 @@ def is_self_signed(certificate, datatype=PEM, dbdir=None): del nsscert return self_signed +class _Name(univ.Choice): + componentType = namedtype.NamedTypes( + namedtype.NamedType('rdnSequence', + univ.SequenceOf()), + ) + class _TBSCertificate(univ.Sequence): componentType = namedtype.NamedTypes( namedtype.NamedType( @@ -204,9 +210,9 @@ class _TBSCertificate(univ.Sequence): tag.tagClassContext, tag.tagFormatSimple, 0))), namedtype.NamedType('serialNumber', univ.Integer()), namedtype.NamedType('signature', univ.Sequence()), - namedtype.NamedType('issuer', univ.Sequence()), + namedtype.NamedType('issuer', _Name()), namedtype.NamedType('validity', univ.Sequence()), - namedtype.NamedType('subject', univ.Sequence()), + namedtype.NamedType('subject', _Name()), namedtype.NamedType('subjectPublicKeyInfo', univ.Sequence()), namedtype.OptionalNamedType( 'issuerUniquedID', @@ -403,7 +409,7 @@ class _GeneralName(univ.Choice): namedtype.NamedType('x400Address', univ.Sequence().subtype( implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) ), - namedtype.NamedType('directoryName', univ.Choice().subtype( + namedtype.NamedType('directoryName', _Name().subtype( implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) ), namedtype.NamedType('ediPartyName', univ.Sequence().subtype( -- 2.5.5 -------------- next part -------------- From 80172d2ebc4d5b1f40206bf527eb3e3f13a0c4ab Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 22 Jul 2016 12:11:59 +1000 Subject: [PATCH 94/94] x509: use NSS enums and OIDs to identify SAN types GeneralName parsing currently relies heavily on strings from NSS. Make the code hopefully less brittle by identifying GeneralName types by NSS enums and, for otherName, the name-type OID also. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/x509.py | 30 +++++++++++++++++++++++------- ipaserver/plugins/cert.py | 19 ++++++++++--------- 2 files changed, 33 insertions(+), 16 deletions(-) diff --git a/ipalib/x509.py b/ipalib/x509.py index 2dc67441c92686826dd24f00a5ad30566cd032da..541609fbc1a53a73eafcff2327e53a292c2d9a3c 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -33,6 +33,7 @@ from __future__ import print_function +import collections import os import sys import base64 @@ -63,10 +64,8 @@ EKU_EMAIL_PROTECTION = '1.3.6.1.5.5.7.3.4' EKU_ANY = '2.5.29.37.0' EKU_PLACEHOLDER = '1.3.6.1.4.1.3319.6.10.16' -SAN_DNSNAME = 'DNS name' -SAN_RFC822NAME = 'RFC822 Name' -SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' -SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' +SAN_UPN = '1.3.6.1.4.1.311.20.2.3' +SAN_KRB5PRINCIPALNAME = '1.3.6.1.5.2.2' _subject_base = None @@ -465,6 +464,10 @@ def _decode_krb5principalname(data): return name +GeneralNameInfo = collections.namedtuple( + 'GeneralNameInfo', ('type', 'desc', 'value')) + + def decode_generalnames(secitem): """ Decode a GeneralNames object (this the data for the Subject @@ -482,12 +485,25 @@ def decode_generalnames(secitem): asn1_names = decoder.decode(secitem.data, asn1Spec=_SubjectAltName())[0] names = [] for nss_name, asn1_name in zip(nss_names, asn1_names): - name_type = nss_name.type_string - if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: + # NOTE: we use the NSS enum to identify the name type. + # (For otherName we also tuple it up with the type-id OID). + # The enum does not correspond exactly to the ASN.1 tags. + # If we ever want to switch to using the true tag numbers, + # the expression to get the tag is: + # + # asn1_name.getComponent().getTagSet()[0].asTuple()[2] + # + if nss_name.type_enum == nss.certOtherName: + oid = str(asn1_name['otherName']['type-id']) + nametype = (nss_name.type_enum, oid) + else: + nametype = nss_name.type_enum + + if nametype == (nss.certOtherName, SAN_KRB5PRINCIPALNAME): name = _decode_krb5principalname(asn1_name['otherName']['value']) else: name = nss_name.name - names.append((name_type, name)) + names.append(GeneralNameInfo(nametype, nss_name.type_string, name)) return names diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index c25965080e40dcbcaa21ab140509eaf2e29d7c61..3e9eda5047b839171e6a0bc96f92927fbb191824 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -559,8 +559,8 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "to the 'userCertificate' attribute of entry '%s'.") % dn) # Validate the subject alt name, if any - for name_type, name in subjectaltname: - if name_type == x509.SAN_DNSNAME: + for name_type, desc, name in subjectaltname: + if name_type == nss.certDNSName: name = unicode(name) alt_principal_obj = None alt_principal_string = unicode(principal) @@ -574,7 +574,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): raise errors.ValidationError( name='csr', error=_("subject alt name type %s is forbidden " - "for user principals") % name_type + "for user principals") % desc ) except errors.NotFound: # We don't want to issue any certificates referencing @@ -591,13 +591,15 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "with subject alt name '%s'.") % name) if alt_principal_string is not None and not bypass_caacl: caacl_check(principal_type, principal, ca, profile_id) - elif name_type in (x509.SAN_OTHERNAME_KRB5PRINCIPALNAME, - x509.SAN_OTHERNAME_UPN): + elif name_type in [ + (nss.certOtherName, x509.SAN_UPN), + (nss.certOtherName, x509.SAN_KRB5PRINCIPALNAME), + ]: if name != principal_string: raise errors.ACIError( info=_("Principal '%s' in subject alt name does not " "match requested principal") % name) - elif name_type == x509.SAN_RFC822NAME: + elif name_type == nss.certRFC822Name: if principal_type == USER: if name not in principal_obj.get('mail', []): raise errors.ValidationError( @@ -610,12 +612,11 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): raise errors.ValidationError( name='csr', error=_("subject alt name type %s is forbidden " - "for non-user principals") % name_type + "for non-user principals") % desc ) else: raise errors.ACIError( - info=_("Subject alt name type %s is forbidden") % - name_type) + info=_("Subject alt name type %s is forbidden") % desc) # Request the certificate result = self.Backend.ra.request_certificate( -- 2.5.5 -------------- next part -------------- From ffde58d7e6fad175049e5ef5c9760978769c49fe Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 15 Aug 2016 15:39:49 +1000 Subject: [PATCH] x509: include otherName DER value in GeneralNameInfo We want to include the whole DER value when we pretty-print unrecognised otherNames, so add a field to the GeneralNameInfo namedtuple and populate it for otherNames. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/x509.py | 13 +++++++++---- ipaserver/plugins/cert.py | 2 +- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/ipalib/x509.py b/ipalib/x509.py index 541609fbc1a53a73eafcff2327e53a292c2d9a3c..e986a97a58aafd3aeab08765a397edbf67c7841a 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -465,7 +465,7 @@ def _decode_krb5principalname(data): GeneralNameInfo = collections.namedtuple( - 'GeneralNameInfo', ('type', 'desc', 'value')) + 'GeneralNameInfo', ('type', 'desc', 'value', 'der_value')) def decode_generalnames(secitem): @@ -477,8 +477,9 @@ def decode_generalnames(secitem): The input is the DER-encoded extension data, without the OCTET STRING header, as an nss SecItem object. - Return a list of tuples of name types (as string, suitable for - presentation) and names (as string, suitable for presentation). + Return a list of ``GeneralNameInfo`` namedtuples. The + ``der_value`` field is set for otherNames, otherwise it is + ``None``. """ nss_names = nss.x509_alt_name(secitem, repr_kind=nss.AsObject) @@ -496,14 +497,18 @@ def decode_generalnames(secitem): if nss_name.type_enum == nss.certOtherName: oid = str(asn1_name['otherName']['type-id']) nametype = (nss_name.type_enum, oid) + der_value = asn1_name['otherName']['value'].asOctets() else: nametype = nss_name.type_enum + der_value = None if nametype == (nss.certOtherName, SAN_KRB5PRINCIPALNAME): name = _decode_krb5principalname(asn1_name['otherName']['value']) else: name = nss_name.name - names.append(GeneralNameInfo(nametype, nss_name.type_string, name)) + + gni = GeneralNameInfo(nametype, nss_name.type_string, name, der_value) + names.append(gni) return names diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 3e9eda5047b839171e6a0bc96f92927fbb191824..9ee0b38c0aeadf2041b7d322417bbeab417b23a6 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -559,7 +559,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "to the 'userCertificate' attribute of entry '%s'.") % dn) # Validate the subject alt name, if any - for name_type, desc, name in subjectaltname: + for name_type, desc, name, der_name in subjectaltname: if name_type == nss.certDNSName: name = unicode(name) alt_principal_obj = None -- 2.5.5 -------------- next part -------------- From d81c6c4cd7432783aaee511f2426f72a9cb1bddf Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 14 Jul 2016 21:36:33 +1000 Subject: [PATCH] cert-show: show subject alternative names Enhance the cert-show command to return subject alternative name values. Fixes: https://fedorahosted.org/freeipa/ticket/6022 --- ipaserver/plugins/cert.py | 130 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 127 insertions(+), 3 deletions(-) diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 9ee0b38c0aeadf2041b7d322417bbeab417b23a6..d4c27a4dd80b2d047cf520524ced6724e5ec329e 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -39,7 +39,7 @@ from ipalib import ngettext from ipalib.constants import IPA_CA_CN from ipalib.crud import Create, PKQuery, Retrieve, Search from ipalib.frontend import Method, Object -from ipalib.parameters import Bytes, DateTime, DNParam, Principal +from ipalib.parameters import Bytes, DateTime, DNParam, DNSNameParam, Principal from ipalib.plugable import Registry from .virtual import VirtualCommand from .baseldap import pkey_to_value @@ -50,6 +50,7 @@ from ipalib.request import context from ipalib import output from ipapython import kerberos from ipapython.dn import DN +from ipapython.ipa_log_manager import root_logger from ipaserver.plugins.service import normalize_principal, validate_realm if six.PY3: @@ -312,9 +313,77 @@ class BaseCertObject(Object): label=_('Serial number (hex)'), flags={'no_create', 'no_update', 'no_search'}, ), + Str( + 'san_rfc822name*', + label=_('Subject email address'), + flags={'no_create', 'no_update', 'no_search'}, + ), + DNSNameParam( + 'san_dnsname*', + label=_('Subject DNS name'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_x400address*', + label=_('Subject X.400 address'), + flags={'no_create', 'no_update', 'no_search'}, + ), + DNParam( + 'san_directoryname*', + label=_('Subject directory name'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_edipartyname*', + label=_('Subject EDI Party name'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_uri*', + label=_('Subject URI'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_ipaddress*', + label=_('Subject IP Address'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_oid*', + label=_('Subject OID'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Principal( + 'san_other_upn*', + label=_('Subject UPN'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Principal( + 'san_other_kpn*', + label=_('Subject Kerberos principal name'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_other*', + label=_('Subject Other Name'), + flags={'no_create', 'no_update', 'no_search'}, + ), ) def _parse(self, obj, full=True): + """Extract certificate-specific data into a result object. + + ``obj`` + Result object containing certificate, into which extracted + data will be inserted. + ``full`` + Whether to include all fields, or only the ones we guess + people want to see most of the time. Also add + recognised otherNames to the generic ``san_other`` + attribute when ``True`` in addition to the specialised + attribute. + + """ cert = obj.get('certificate') if cert is not None: cert = x509.load_certificate(cert) @@ -329,11 +398,66 @@ class BaseCertObject(Object): obj['sha1_fingerprint'] = unicode( nss.data_to_hex(nss.sha1_digest(cert.der_data), 64)[0]) + try: + ext_san = cert.get_extension(nss.SEC_OID_X509_SUBJECT_ALT_NAME) + general_names = x509.decode_generalnames(ext_san.value) + except KeyError: + general_names = [] + + for name_type, desc, name, der_name in general_names: + try: + self._add_san_attribute( + obj, full, name_type, name, der_name) + except Exception as e: + # Invalid GeneralName (i.e. not a valid X.509 cert); + # don't fail but log something about it + root_logger.warning( + "Encountered bad GeneralName; skipping", exc_info=True) + serial_number = obj.get('serial_number') if serial_number is not None: obj['serial_number_hex'] = u'0x%X' % serial_number + def _add_san_attribute( + self, obj, full, name_type, name, der_name): + name_type_map = { + nss.certRFC822Name: 'san_rfc822name', + nss.certDNSName: 'san_dnsname', + nss.certX400Address: 'san_x400address', + nss.certDirectoryName: 'san_directoryname', + nss.certEDIPartyName: 'san_edipartyname', + nss.certURI: 'san_uri', + nss.certIPAddress: 'san_ipaddress', + nss.certRegisterID: 'san_oid', + (nss.certOtherName, x509.SAN_UPN): 'san_other_upn', + (nss.certOtherName, x509.SAN_KRB5PRINCIPALNAME): 'san_other_kpn', + } + default_attrs = { + 'san_rfc822name', 'san_dnsname', 'san_directoryname', + 'san_other_upn', 'san_other_kpn', + } + + attr_name = name_type_map.get(name_type, 'san_other') + + if full or attr_name in default_attrs: + if attr_name != 'san_other': + name_formatted = name + else: + # display as "OID : b64(DER)" + name_formatted = u'{}:{}'.format( + name_type[1], base64.b64encode(der_name)) + attr_value = self.params[attr_name].type(name_formatted) + obj.setdefault(attr_name, []).append(attr_value) + + if full and attr_name.startswith('san_other_'): + # also include known otherName in generic otherName attribute + name_formatted = u'{}:{}'.format( + name_type[1], base64.b64encode(der_name)) + attr_value = self.params['san_other'].type(name_formatted) + obj.setdefault('san_other', []).append(attr_value) + + class BaseCertMethod(Method): def get_options(self): yield Str('cacn?', @@ -622,7 +746,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): result = self.Backend.ra.request_certificate( csr, profile_id, ca_id, request_type=request_type) if not raw: - self.obj._parse(result) + self.obj._parse(result, all) result['request_id'] = int(result['request_id']) # Success? Then add it to the principal's entry @@ -800,7 +924,7 @@ class cert_show(Retrieve, CertMethod, VirtualCommand): if not raw: result['certificate'] = result['certificate'].replace('\r\n', '') - self.obj._parse(result) + self.obj._parse(result, all) result['revoked'] = ('revocation_reason' in result) self.obj._fill_owners(result) -- 2.5.5 From jcholast at redhat.com Tue Aug 23 09:53:02 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 23 Aug 2016 11:53:02 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add In-Reply-To: <07734948-b57d-79a2-23cf-97bd7aacf08f@redhat.com> References: <6b7ecf18-952c-1c2e-5a35-744dc3fe434b@redhat.com> <07734948-b57d-79a2-23cf-97bd7aacf08f@redhat.com> Message-ID: <50e05a09-f620-6a5e-fbdf-04a0f8a6f6b8@redhat.com> On 22.8.2016 19:08, Tomas Krizek wrote: > I've attached the updated patch. Hopefully I didn't forget anything else > this time. > > > On 08/22/2016 05:48 PM, Martin Basti wrote: >> >> On 22.08.2016 10:22, Tomas Krizek wrote: >>> >>> Seems like a good idea, I'm attaching the updated patch. Autofill >>> does work when the param is required. >>> >>> >>> On 08/19/2016 04:19 PM, Martin Basti wrote: >>>> >>>> >>>> >>>> On 16.08.2016 17:35, Tomas Krizek wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes an error message when user provides an >>>>> empty key while adding otp token. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6200 >>>>> >>>>> >>>>> >>>> >>>> I'm curious why we don't fix it here: >>>> >>>> OTPTokenKey('ipatokenotpkey?', >>>> cli_name='key', >>>> label=_('Key'), >>>> doc=_('Token secret (Base32; default: random)'), >>>> default_from=lambda: os.urandom(KEY_LENGTH), >>>> autofill=True, >>>> flags=('no_display', 'no_update', 'no_search'), >>>> ), >>>> >>>> >>>> If OTPTokenKey is mandratory, it should be required param (autofill >>>> should work in this case too) >>>> >>>> Martin^2 >>> >>> -- >>> Tomas Krizek >> >> You changed API, you must regenerate API.txt (./makeapi) and increment >> minor version in VERSION file >> >> Option 'ipatokenotpkey?' in command 'otptoken_add/1' in API file not found >> Options count in otptoken_add of 22 doesn't match expected: 23 >> Option ipatokenotpkey of command otptoken_add in ipalib, not in API file: >> OTPTokenKey('ipatokenotpkey', autofill=True, cli_name='key') NACK, this is a backward incompatible change. AFAICT the option should remain optional, see the doc string: Token secret (Base32; default: random) ^^^^^^^^^^^^^^^ -- Jan Cholasta From tkrizek at redhat.com Tue Aug 23 10:15:45 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Tue, 23 Aug 2016 12:15:45 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add In-Reply-To: <50e05a09-f620-6a5e-fbdf-04a0f8a6f6b8@redhat.com> References: <6b7ecf18-952c-1c2e-5a35-744dc3fe434b@redhat.com> <07734948-b57d-79a2-23cf-97bd7aacf08f@redhat.com> <50e05a09-f620-6a5e-fbdf-04a0f8a6f6b8@redhat.com> Message-ID: In that case, the first version of the patch solves the issue. I'm attaching the patch once again, but it's the same as the one in the original message. On 08/23/2016 11:53 AM, Jan Cholasta wrote: > On 22.8.2016 19:08, Tomas Krizek wrote: >> I've attached the updated patch. Hopefully I didn't forget anything else >> this time. >> >> >> On 08/22/2016 05:48 PM, Martin Basti wrote: >>> >>> On 22.08.2016 10:22, Tomas Krizek wrote: >>>> >>>> Seems like a good idea, I'm attaching the updated patch. Autofill >>>> does work when the param is required. >>>> >>>> >>>> On 08/19/2016 04:19 PM, Martin Basti wrote: >>>>> >>>>> >>>>> >>>>> On 16.08.2016 17:35, Tomas Krizek wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patch fixes an error message when user provides an >>>>>> empty key while adding otp token. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6200 >>>>>> >>>>>> >>>>>> >>>>> >>>>> I'm curious why we don't fix it here: >>>>> >>>>> OTPTokenKey('ipatokenotpkey?', >>>>> cli_name='key', >>>>> label=_('Key'), >>>>> doc=_('Token secret (Base32; default: random)'), >>>>> default_from=lambda: os.urandom(KEY_LENGTH), >>>>> autofill=True, >>>>> flags=('no_display', 'no_update', 'no_search'), >>>>> ), >>>>> >>>>> >>>>> If OTPTokenKey is mandratory, it should be required param (autofill >>>>> should work in this case too) >>>>> >>>>> Martin^2 >>>> >>>> -- >>>> Tomas Krizek >>> >>> You changed API, you must regenerate API.txt (./makeapi) and increment >>> minor version in VERSION file >>> >>> Option 'ipatokenotpkey?' in command 'otptoken_add/1' in API file not >>> found >>> Options count in otptoken_add of 22 doesn't match expected: 23 >>> Option ipatokenotpkey of command otptoken_add in ipalib, not in API >>> file: >>> OTPTokenKey('ipatokenotpkey', autofill=True, cli_name='key') > > NACK, this is a backward incompatible change. > > AFAICT the option should remain optional, see the doc string: > > Token secret (Base32; default: random) > ^^^^^^^^^^^^^^^ > -- Tomas Krizek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tkrizek-0003-Validate-key-in-otptoken-add.patch Type: text/x-patch Size: 1046 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Aug 23 10:32:47 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 23 Aug 2016 12:32:47 +0200 Subject: [Freeipa-devel] [freeipa PR#12] Tests: Duplicate declaration on variables in ID views tests (+pushed) In-Reply-To: References: Message-ID: mirielka's pull request #12: "Tests: Duplicate declaration on variables in ID views tests" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/12 From freeipa-github-notification at redhat.com Tue Aug 23 10:32:49 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 23 Aug 2016 12:32:49 +0200 Subject: [Freeipa-devel] [freeipa PR#12] Tests: Duplicate declaration on variables in ID views tests (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request Fixed upstream master: https://fedorahosted.org/freeipa/changeset/fef4b953099b7d22f257bf32b6aa5d422a2831e5 See the full comment at https://github.com/freeipa/freeipa/pull/12#issuecomment-241691499 From freeipa-github-notification at redhat.com Tue Aug 23 10:32:51 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 23 Aug 2016 12:32:51 +0200 Subject: [Freeipa-devel] [freeipa PR#12] Tests: Duplicate declaration on variables in ID views tests (closed) In-Reply-To: References: Message-ID: mirielka's pull request #12: "Tests: Duplicate declaration on variables in ID views tests" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/12 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/12/head:pr12 git checkout pr12 From pvoborni at redhat.com Tue Aug 23 10:41:25 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Aug 2016 12:41:25 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <57AB47D4.5030400@redhat.com> References: <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> <20160808152007.v5fq23paiaa55khf@redhat.com> <57A8A57E.3070003@redhat.com> <57A9BD64.5050308@redhat.com> <20160809113803.2jehpfuxnrg4wozr@redhat.com> <57AACDD9.7070102@redhat.com> <20160810070337.kt4auntwnvznvplb@redhat.com> <20160810105131.74jbejwx5lbv54g6@redhat.com> <57AB3C11.9030008@redhat.com> <57AB47D4.5030400@redhat.com> Message-ID: <2d9299fd-1a50-6d2c-c65c-95cf7737033e@redhat.com> On 08/10/2016 05:27 PM, thierry bordaz wrote: > > > On 08/10/2016 04:37 PM, thierry bordaz wrote: >> >> >> On 08/10/2016 12:51 PM, Alexander Bokovoy wrote: >>> On Wed, 10 Aug 2016, Alexander Bokovoy wrote: >>>> On Wed, 10 Aug 2016, thierry bordaz wrote: >>>>> >>>>> >>>>> On 08/09/2016 01:38 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 09 Aug 2016, thierry bordaz wrote: >>>>>>> >>>>>>> >>>>>>> On 08/09/2016 12:49 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08.08.2016 17:30, thierry bordaz wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/08/2016 05:20 PM, Alexander Bokovoy wrote: >>>>>>>>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>>>>>>>>>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>>>>>>>>>>> On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>>>>>>>>>>> On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>>>>>>>>>>> On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>>>> When SSSD resolves AD users on behalf of slapi-nis, it >>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>> accept any >>>>>>>>>>>>>>>>>> user identifier, including user principal name (UPN) >>>>>>>>>>>>>>>>>> which may be >>>>>>>>>>>>>>>>>> different than the canonical user name which SSSD >>>>>>>>>>>>>>>>>> returns. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As result, the entry created by slapi-nis will be using >>>>>>>>>>>>>>>>> canonical user >>>>>>>>>>>>>>>>>> name but the filter for search will refer to the >>>>>>>>>>>>>>>>>> original (aliased) >>>>>>>>>>>>>>>>>> name. The search will not match the newly created entry. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The issue is fixed in slapi-nis-0.56.1 by returning >>>>>>>>>>>>>>>>>> two values for >>>>>>>>>>>>>>>>>> 'uid' attribute: the canonical one and the aliased >>>>>>>>>>>>>>>>>> one. This way the >>>>>>>>>>>>>>>>>> search will match. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Standard LDAP schema allows multiple values for 'uid' >>>>>>>>>>>>>>>>>> attribute. We >>>>>>>>>>>>>>>>>> actually use the same trick for 'cn' attribute in the >>>>>>>>>>>>>>>>>> groups map >>>>>>>>>>>>>>>>>> already. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> should we bump requires to slapi-nis-0.56.1 in >>>>>>>>>>>>>>>>> freeipa.spec? >>>>>>>>>>>>>>>> No, this is not required. In Fedora we'll submit a >>>>>>>>>>>>>>>> combined update -- >>>>>>>>>>>>>>>> I've built slapi-nis-0.56.1-1 packages for f24, f25, and >>>>>>>>>>>>>>>> rawhide already >>>>>>>>>>>>>>>> but did not submit a Bodhi request. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> How is combined updated related to requires to >>>>>>>>>>>>>>> slapi-nis-0.56.1? >>>>>>>>>>>>>>> It will not prevent tu update freeipa without new slapi-nis. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>>> dnf update freeipa-server. >>>>>>>>>>>>>> An update file in FreeIPA that is proposed by this patch >>>>>>>>>>>>>> does not affect >>>>>>>>>>>>>> operation of the older slapi-nis deployment once update is >>>>>>>>>>>>>> applied. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Is '%first' returning the first value of the attribute 'uid' ? >>>>>>>>>>>>> If there are several values (canonical, alias,... ), does >>>>>>>>>>>>> the order matters ? >>>>>>>>>>>> We insert the canonical one first and it seems that 389-ds >>>>>>>>>>>> does not >>>>>>>>>>>> change the order, at least in my tests. You can see the >>>>>>>>>>>> output in the >>>>>>>>>>>> bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 >>>>>>>>>>> >>>>>>>>>>> From ldap pov >>>>>>>>>>> (https://tools.ietf.org/html/rfc4511#section-4.1.7) the order >>>>>>>>>>> of the values is not preserved. >>>>>>>>>>> I think it is a bit risky to rely on a specific order >>>>>>>>>>> especially with complex updates (adding several values in a >>>>>>>>>>> single mod, replace) and replication. >>>>>>>>>>> would it help to add canonical value with a subtype (e.g. >>>>>>>>>>> 'uid;canonical: ') ? >>>>>>>>>> Not sure how what you are mention is relevant here. We talk about >>>>>>>>>> slapi-nis map cache entries which are not modified, replaced or >>>>>>>>>> replicated anywhere by anything other than slapi-nis itself. When >>>>>>>>>> entries are changed by slapi-nis, they are regenerated from >>>>>>>>>> scratch. >>>>>>>>>> >>>>>>>>>> Your worries do not apply here. >>>>>>>>> ok. >>>>>>>>> I understand my mistake, I was thinking the compat entry had a >>>>>>>>> associated real entry in ldap and this real entry had two uid >>>>>>>>> values. >>>>>>>>> >>>>>>>> >>>>>>>> So, could you provide ack thierry? >>>>>>>> >>>>>>>> Martin >>>>>>> >>>>>>> Sure but I would have to test first :-) >>>>>>> >>>>>>> Alexander, how can I test this ? >>>>>> slapi-nis 0.56.1-1 packages are available in koji for f24-f26: >>>>>> http://koji.fedoraproject.org/koji/packageinfo?packageID=6609 >>>>> >>>>> Thanks Alexander. So to test this change is there an other way >>>>> (simpler) than setting up AD/trust ? >>>> I don't think so. We don't have UPNs in FreeIPA on the level of >>>> identity >>>> lookups and we don't allow to lookup identity by email, so you are left >>>> with using a proper AD trust and UPN suffixes in AD forest. >>> Attached is an updated patch that adds versioned require of slapi-nis >>> which supports the feature. >>> >>> >> >> Thanks to Lenka, I was able to test the patch with AD trust and a UPN >> suffix. >> >> The tests looks good as 'getent' on a AD user returns user at ADdomain. >> >> Now if I remove the config change in "cn=users,cn=Schema >> Compatibility,cn=plugins,cn=config", I get the same results i.e: >> getent passwd upnuser at UPNsuffix.com >> upnuser at dom-221.idm.lab.eng.brq.redhat.com:*:1965201133:1965201133:UPN >> User:/: >> >> >> How can I check slapi-nis gets the first value ? >> >> thanks >> thierry > acceptance is now completed (successfully). ACK > bump so ACKed ab's 213-1 fixes https://fedorahosted.org/freeipa/ticket/6138 ? -- Petr Vobornik From pvoborni at redhat.com Tue Aug 23 10:42:00 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Aug 2016 12:42:00 +0200 Subject: [Freeipa-devel] [PATCH 0035] Remove Custodia server keys from LDAP In-Reply-To: <0e0ece56-30cc-a2f5-2fd3-72370a498481@redhat.com> References: <0e0ece56-30cc-a2f5-2fd3-72370a498481@redhat.com> Message-ID: <8e8db094-ae33-76cc-0ab7-46784708d98b@redhat.com> On 08/11/2016 04:13 PM, Martin Basti wrote: > > > On 08.08.2016 16:10, Christian Heimes wrote: >> The server-del plugin now removes the Custodia keys for encryption and >> key signing from LDAP. >> >> https://fedorahosted.org/freeipa/ticket/6015 >> >> > ACK for master > > For 4.3, it requires new patch > > Martin > bump -- Petr Vobornik From pvoborni at redhat.com Tue Aug 23 10:49:46 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Aug 2016 12:49:46 +0200 Subject: [Freeipa-devel] [PATCH 0034] Secure permissions of Custodia server.keys In-Reply-To: <83082726-8ced-5334-2115-436106970244@redhat.com> References: <164526c4-5b07-669f-3887-0f5772d348a7@redhat.com> <83082726-8ced-5334-2115-436106970244@redhat.com> Message-ID: On 08/09/2016 01:53 PM, Martin Basti wrote: > > > On 08.08.2016 16:09, Christian Heimes wrote: >> I have split up patch 0032 into two smaller patches. This patch only >> addresses the server.keys file. >> >> Custodia's server.keys file contain the private RSA keys for encrypting >> and signing Custodia messages. The file was created with permission 644 >> and is only secured by permission 700 of the directory >> /etc/ipa/custodia. The installer and upgrader ensure that the file >> has 600. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1353936 >> https://fedorahosted.org/freeipa/ticket/6056 >> >> > Pylint is running, please wait ... > ************* Module ipapython.secrets.kem > ipapython/secrets/kem.py:147: [E0602(undefined-variable), newServerKeys] > Undefined variable 'os') > ipapython/secrets/kem.py:148: [E0602(undefined-variable), newServerKeys] > Undefined variable 'os') > ************* Module ipaserver.install.custodiainstance > ipaserver/install/custodiainstance.py:77: [E0602(undefined-variable), > CustodiaInstance.upgrade_instance] Undefined variable 'stat') > > > this review looks stuck -- Petr Vobornik From freeipa-github-notification at redhat.com Tue Aug 23 11:29:04 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 23 Aug 2016 13:29:04 +0200 Subject: [Freeipa-devel] [freeipa PR#11] Removed unwanted line break from RefererError Dialog message (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d5a3f10a854f998087fe2c22fcbbbfdd2aba50ce See the full comment at https://github.com/freeipa/freeipa/pull/11#issuecomment-241702681 From freeipa-github-notification at redhat.com Tue Aug 23 11:29:06 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 23 Aug 2016 13:29:06 +0200 Subject: [Freeipa-devel] [freeipa PR#11] Removed unwanted line break from RefererError Dialog message (+pushed) In-Reply-To: References: Message-ID: Akasurde's pull request #11: "Removed unwanted line break from RefererError Dialog message" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/11 From freeipa-github-notification at redhat.com Tue Aug 23 11:29:07 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 23 Aug 2016 13:29:07 +0200 Subject: [Freeipa-devel] [freeipa PR#11] Removed unwanted line break from RefererError Dialog message (closed) In-Reply-To: References: Message-ID: Akasurde's pull request #11: "Removed unwanted line break from RefererError Dialog message" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/11 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/11/head:pr11 git checkout pr11 From slaznick at redhat.com Tue Aug 23 11:58:44 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Tue, 23 Aug 2016 13:58:44 +0200 Subject: [Freeipa-devel] [PATCH 0065] Fix ugly quit during external CA installation Message-ID: https://fedorahosted.org/freeipa/ticket/6230 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0065-Make-installer-quit-more-nicely-on-external-CA-insta.patch Type: text/x-patch Size: 1300 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Aug 23 12:07:24 2016 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 23 Aug 2016 14:07:24 +0200 Subject: [Freeipa-devel] [freeipa PR#13] Handled empty hostname in server-del command (opened) In-Reply-To: References: Message-ID: Akasurde's pull request #13: "Handled empty hostname in server-del command" was opened PR body: Fixes: https://fedorahosted.org/freeipa/ticket/6248 Signed-off-by: Abhijeet Kasurde See the full pull-request at https://github.com/freeipa/freeipa/pull/13 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/13/head:pr13 git checkout pr13 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-13.patch URL: From tbordaz at redhat.com Tue Aug 23 13:17:20 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 23 Aug 2016 15:17:20 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <2d9299fd-1a50-6d2c-c65c-95cf7737033e@redhat.com> References: <57A89011.9050103@redhat.com> <20160808142052.23rcbyd7llbljbfi@redhat.com> <57A89D5E.60807@redhat.com> <20160808152007.v5fq23paiaa55khf@redhat.com> <57A8A57E.3070003@redhat.com> <57A9BD64.5050308@redhat.com> <20160809113803.2jehpfuxnrg4wozr@redhat.com> <57AACDD9.7070102@redhat.com> <20160810070337.kt4auntwnvznvplb@redhat.com> <20160810105131.74jbejwx5lbv54g6@redhat.com> <57AB3C11.9030008@redhat.com> <57AB47D4.5030400@redhat.com> <2d9299fd-1a50-6d2c-c65c-95cf7737033e@redhat.com> Message-ID: <57BC4CE0.1020505@redhat.com> On 08/23/2016 12:41 PM, Petr Vobornik wrote: > On 08/10/2016 05:27 PM, thierry bordaz wrote: >> >> On 08/10/2016 04:37 PM, thierry bordaz wrote: >>> >>> On 08/10/2016 12:51 PM, Alexander Bokovoy wrote: >>>> On Wed, 10 Aug 2016, Alexander Bokovoy wrote: >>>>> On Wed, 10 Aug 2016, thierry bordaz wrote: >>>>>> >>>>>> On 08/09/2016 01:38 PM, Alexander Bokovoy wrote: >>>>>>> On Tue, 09 Aug 2016, thierry bordaz wrote: >>>>>>>> >>>>>>>> On 08/09/2016 12:49 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> On 08.08.2016 17:30, thierry bordaz wrote: >>>>>>>>>> >>>>>>>>>> On 08/08/2016 05:20 PM, Alexander Bokovoy wrote: >>>>>>>>>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 08/08/2016 04:20 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>> On Mon, 08 Aug 2016, thierry bordaz wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/08/2016 10:56 AM, Alexander Bokovoy wrote: >>>>>>>>>>>>>>> On Mon, 08 Aug 2016, Lukas Slebodnik wrote: >>>>>>>>>>>>>>>> On (08/08/16 11:35), Alexander Bokovoy wrote: >>>>>>>>>>>>>>>>> On Mon, 08 Aug 2016, Martin Basti wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 08.08.2016 09:34, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>>>>> When SSSD resolves AD users on behalf of slapi-nis, it >>>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>> accept any >>>>>>>>>>>>>>>>>>> user identifier, including user principal name (UPN) >>>>>>>>>>>>>>>>>>> which may be >>>>>>>>>>>>>>>>>>> different than the canonical user name which SSSD >>>>>>>>>>>>>>>>>>> returns. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> As result, the entry created by slapi-nis will be using >>>>>>>>>>>>>>>>>> canonical user >>>>>>>>>>>>>>>>>>> name but the filter for search will refer to the >>>>>>>>>>>>>>>>>>> original (aliased) >>>>>>>>>>>>>>>>>>> name. The search will not match the newly created entry. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The issue is fixed in slapi-nis-0.56.1 by returning >>>>>>>>>>>>>>>>>>> two values for >>>>>>>>>>>>>>>>>>> 'uid' attribute: the canonical one and the aliased >>>>>>>>>>>>>>>>>>> one. This way the >>>>>>>>>>>>>>>>>>> search will match. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Standard LDAP schema allows multiple values for 'uid' >>>>>>>>>>>>>>>>>>> attribute. We >>>>>>>>>>>>>>>>>>> actually use the same trick for 'cn' attribute in the >>>>>>>>>>>>>>>>>>> groups map >>>>>>>>>>>>>>>>>>> already. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6138 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> should we bump requires to slapi-nis-0.56.1 in >>>>>>>>>>>>>>>>>> freeipa.spec? >>>>>>>>>>>>>>>>> No, this is not required. In Fedora we'll submit a >>>>>>>>>>>>>>>>> combined update -- >>>>>>>>>>>>>>>>> I've built slapi-nis-0.56.1-1 packages for f24, f25, and >>>>>>>>>>>>>>>>> rawhide already >>>>>>>>>>>>>>>>> but did not submit a Bodhi request. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> How is combined updated related to requires to >>>>>>>>>>>>>>>> slapi-nis-0.56.1? >>>>>>>>>>>>>>>> It will not prevent tu update freeipa without new slapi-nis. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>>>> dnf update freeipa-server. >>>>>>>>>>>>>>> An update file in FreeIPA that is proposed by this patch >>>>>>>>>>>>>>> does not affect >>>>>>>>>>>>>>> operation of the older slapi-nis deployment once update is >>>>>>>>>>>>>>> applied. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is '%first' returning the first value of the attribute 'uid' ? >>>>>>>>>>>>>> If there are several values (canonical, alias,... ), does >>>>>>>>>>>>>> the order matters ? >>>>>>>>>>>>> We insert the canonical one first and it seems that 389-ds >>>>>>>>>>>>> does not >>>>>>>>>>>>> change the order, at least in my tests. You can see the >>>>>>>>>>>>> output in the >>>>>>>>>>>>> bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2 >>>>>>>>>>>> From ldap pov >>>>>>>>>>>> (https://tools.ietf.org/html/rfc4511#section-4.1.7) the order >>>>>>>>>>>> of the values is not preserved. >>>>>>>>>>>> I think it is a bit risky to rely on a specific order >>>>>>>>>>>> especially with complex updates (adding several values in a >>>>>>>>>>>> single mod, replace) and replication. >>>>>>>>>>>> would it help to add canonical value with a subtype (e.g. >>>>>>>>>>>> 'uid;canonical: ') ? >>>>>>>>>>> Not sure how what you are mention is relevant here. We talk about >>>>>>>>>>> slapi-nis map cache entries which are not modified, replaced or >>>>>>>>>>> replicated anywhere by anything other than slapi-nis itself. When >>>>>>>>>>> entries are changed by slapi-nis, they are regenerated from >>>>>>>>>>> scratch. >>>>>>>>>>> >>>>>>>>>>> Your worries do not apply here. >>>>>>>>>> ok. >>>>>>>>>> I understand my mistake, I was thinking the compat entry had a >>>>>>>>>> associated real entry in ldap and this real entry had two uid >>>>>>>>>> values. >>>>>>>>>> >>>>>>>>> So, could you provide ack thierry? >>>>>>>>> >>>>>>>>> Martin >>>>>>>> Sure but I would have to test first :-) >>>>>>>> >>>>>>>> Alexander, how can I test this ? >>>>>>> slapi-nis 0.56.1-1 packages are available in koji for f24-f26: >>>>>>> http://koji.fedoraproject.org/koji/packageinfo?packageID=6609 >>>>>> Thanks Alexander. So to test this change is there an other way >>>>>> (simpler) than setting up AD/trust ? >>>>> I don't think so. We don't have UPNs in FreeIPA on the level of >>>>> identity >>>>> lookups and we don't allow to lookup identity by email, so you are left >>>>> with using a proper AD trust and UPN suffixes in AD forest. >>>> Attached is an updated patch that adds versioned require of slapi-nis >>>> which supports the feature. >>>> >>>> >>> Thanks to Lenka, I was able to test the patch with AD trust and a UPN >>> suffix. >>> >>> The tests looks good as 'getent' on a AD user returns user at ADdomain. >>> >>> Now if I remove the config change in "cn=users,cn=Schema >>> Compatibility,cn=plugins,cn=config", I get the same results i.e: >>> getent passwd upnuser at UPNsuffix.com >>> upnuser at dom-221.idm.lab.eng.brq.redhat.com:*:1965201133:1965201133:UPN >>> User:/: >>> >>> >>> How can I check slapi-nis gets the first value ? >>> >>> thanks >>> thierry >> acceptance is now completed (successfully). ACK >> > bump > > so ACKed ab's 213-1 fixes https://fedorahosted.org/freeipa/ticket/6138 ? > Yes that is my understanding. patch 213-1 fixes #6138. I verified that lookup of UPN entries does return the domain. But did not know how to check that entries with multiple uid values only returns the first value. From freeipa-github-notification at redhat.com Tue Aug 23 14:08:57 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 23 Aug 2016 16:08:57 +0200 Subject: [Freeipa-devel] [freeipa PR#13] Handled empty hostname in server-del command (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request NACK, see inline comments See the full comment at https://github.com/freeipa/freeipa/pull/13#issuecomment-241742765 From bind-dyndb-ldap-github-notification at redhat.com Tue Aug 23 14:08:48 2016 From: bind-dyndb-ldap-github-notification at redhat.com (pspacek) Date: Tue, 23 Aug 2016 16:08:48 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#1] [WIP] Port bind-dyndb-ldap to BIND 9.11 (opened) In-Reply-To: References: Message-ID: pspacek's pull request #1: "[WIP] Port bind-dyndb-ldap to BIND 9.11" was opened PR body: This is work in progress patch set, do not merge it yet. See the full pull-request at https://github.com/freeipa/bind-dyndb-ldap/pull/1 ... or pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/1/head:pr1 git checkout pr1 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bind-dyndb-ldap-pr-1.patch URL: From freeipa-github-notification at redhat.com Tue Aug 23 14:43:20 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Tue, 23 Aug 2016 16:43:20 +0200 Subject: [Freeipa-devel] [freeipa PR#14] Tests: Failing intree tests (opened) In-Reply-To: References: Message-ID: mirielka's pull request #14: "Tests: Failing intree tests" was opened PR body: Fixing failing tests in: test_ipalib/test_plugable test_ipalib/test_rpc test_ipaserver/test_ldap All issues were discussed with Jan Cholasta and are results of thin client implementation. See the full pull-request at https://github.com/freeipa/freeipa/pull/14 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/14/head:pr14 git checkout pr14 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-14.patch URL: From freeipa-github-notification at redhat.com Wed Aug 24 04:43:24 2016 From: freeipa-github-notification at redhat.com (Akasurde) Date: Wed, 24 Aug 2016 06:43:24 +0200 Subject: [Freeipa-devel] [freeipa PR#13] Handled empty hostname in server-del command (synchronize) In-Reply-To: References: Message-ID: Akasurde's pull request #13: "Handled empty hostname in server-del command" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/13 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/13/head:pr13 git checkout pr13 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-13.patch URL: From freeipa-github-notification at redhat.com Wed Aug 24 09:07:49 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 24 Aug 2016 11:07:49 +0200 Subject: [Freeipa-devel] [freeipa PR#15] Secure permissions of Custodia server.keys (opened) In-Reply-To: References: Message-ID: tiran's pull request #15: "Secure permissions of Custodia server.keys" was opened PR body: Custodia's server.keys file contain the private RSA keys for encrypting and signing Custodia messages. The file was created with permission 644 and is only secured by permission 700 of the directory /etc/ipa/custodia. The installer and upgrader ensure that the file has 600. https://bugzilla.redhat.com/show_bug.cgi?id=1353936 https://fedorahosted.org/freeipa/ticket/6056 See the full pull-request at https://github.com/freeipa/freeipa/pull/15 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/15/head:pr15 git checkout pr15 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-15.patch URL: From cheimes at redhat.com Wed Aug 24 09:09:49 2016 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 24 Aug 2016 11:09:49 +0200 Subject: [Freeipa-devel] [PATCH 0034] Secure permissions of Custodia server.keys In-Reply-To: References: <164526c4-5b07-669f-3887-0f5772d348a7@redhat.com> <83082726-8ced-5334-2115-436106970244@redhat.com> Message-ID: <54743046-5e11-c1f1-6434-659f4ca7aa6d@redhat.com> On 2016-08-23 12:49, Petr Vobornik wrote: > On 08/09/2016 01:53 PM, Martin Basti wrote: >> >> >> On 08.08.2016 16:09, Christian Heimes wrote: >>> I have split up patch 0032 into two smaller patches. This patch only >>> addresses the server.keys file. >>> >>> Custodia's server.keys file contain the private RSA keys for encrypting >>> and signing Custodia messages. The file was created with permission 644 >>> and is only secured by permission 700 of the directory >>> /etc/ipa/custodia. The installer and upgrader ensure that the file >>> has 600. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1353936 >>> https://fedorahosted.org/freeipa/ticket/6056 >>> >>> >> Pylint is running, please wait ... >> ************* Module ipapython.secrets.kem >> ipapython/secrets/kem.py:147: [E0602(undefined-variable), newServerKeys] >> Undefined variable 'os') >> ipapython/secrets/kem.py:148: [E0602(undefined-variable), newServerKeys] >> Undefined variable 'os') >> ************* Module ipaserver.install.custodiainstance >> ipaserver/install/custodiainstance.py:77: [E0602(undefined-variable), >> CustodiaInstance.upgrade_instance] Undefined variable 'stat') >> >> >> > > this review looks stuck Thanks, I didn't notice that it was stuck. I have pushed it to github and made a PR: https://github.com/freeipa/freeipa/pull/15 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From cheimes at redhat.com Wed Aug 24 09:25:31 2016 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 24 Aug 2016 11:25:31 +0200 Subject: [Freeipa-devel] [PATCH 0035] Remove Custodia server keys from LDAP In-Reply-To: <8e8db094-ae33-76cc-0ab7-46784708d98b@redhat.com> References: <0e0ece56-30cc-a2f5-2fd3-72370a498481@redhat.com> <8e8db094-ae33-76cc-0ab7-46784708d98b@redhat.com> Message-ID: <8bd66a1d-ccab-ebf1-5279-af2ae1bdcd34@redhat.com> On 2016-08-23 12:42, Petr Vobornik wrote: > On 08/11/2016 04:13 PM, Martin Basti wrote: >> >> >> On 08.08.2016 16:10, Christian Heimes wrote: >>> The server-del plugin now removes the Custodia keys for encryption and >>> key signing from LDAP. >>> >>> https://fedorahosted.org/freeipa/ticket/6015 >>> >>> >> ACK for master >> >> For 4.3, it requires new patch >> >> Martin >> > > bump I haven't worked out a patch for 4.3. The server_del plugin in 4.3 is much simpler than in 4.4. It's not possible to hook the clean-up code to server_del like I did for 4.4. I would have to rewrite and redesign the patch completely which I neither have the time nor resources to at the moment. I vote for WONTFIX for 4.3. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mbasti at redhat.com Wed Aug 24 10:21:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Aug 2016 12:21:45 +0200 Subject: [Freeipa-devel] [PATCH 0035] Remove Custodia server keys from LDAP In-Reply-To: <8bd66a1d-ccab-ebf1-5279-af2ae1bdcd34@redhat.com> References: <0e0ece56-30cc-a2f5-2fd3-72370a498481@redhat.com> <8e8db094-ae33-76cc-0ab7-46784708d98b@redhat.com> <8bd66a1d-ccab-ebf1-5279-af2ae1bdcd34@redhat.com> Message-ID: <5326ea79-a4f9-17d7-639c-eb733a73ba5b@redhat.com> On 24.08.2016 11:25, Christian Heimes wrote: > On 2016-08-23 12:42, Petr Vobornik wrote: >> On 08/11/2016 04:13 PM, Martin Basti wrote: >>> >>> On 08.08.2016 16:10, Christian Heimes wrote: >>>> The server-del plugin now removes the Custodia keys for encryption and >>>> key signing from LDAP. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6015 >>>> >>>> >>> ACK for master >>> >>> For 4.3, it requires new patch >>> >>> Martin >>> >> bump > I haven't worked out a patch for 4.3. The server_del plugin in 4.3 is > much simpler than in 4.4. It's not possible to hook the clean-up code to > server_del like I did for 4.4. I would have to rewrite and redesign the > patch completely which I neither have the time nor resources to at the > moment. > > I vote for WONTFIX for 4.3. +1 Martin^2 > > Christian > > From freeipa-github-notification at redhat.com Wed Aug 24 10:33:51 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 24 Aug 2016 12:33:51 +0200 Subject: [Freeipa-devel] [freeipa PR#16] Require httpd 2.4.6-31 with mod_proxy Unix socket support (opened) In-Reply-To: References: Message-ID: tiran's pull request #16: "Require httpd 2.4.6-31 with mod_proxy Unix socket support" was opened PR body: httpd 2.4.6-6 does not support mod_proxy ProxyPass for Unix sockets. The feature is provided by 2.4.7 upstream was backported to 2.4.6-31 (bz1168081). It's required to proxy Custodia. https://bugzilla.redhat.com/show_bug.cgi?id=1168081 https://httpd.apache.org/docs/trunk/mod/mod_proxy.html#proxypass https://fedorahosted.org/freeipa/ticket/6251 Signed-off-by: Christian Heimes See the full pull-request at https://github.com/freeipa/freeipa/pull/16 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/16/head:pr16 git checkout pr16 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-16.patch URL: From tkrizek at redhat.com Wed Aug 24 11:32:40 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Wed, 24 Aug 2016 13:32:40 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add In-Reply-To: References: <6b7ecf18-952c-1c2e-5a35-744dc3fe434b@redhat.com> <07734948-b57d-79a2-23cf-97bd7aacf08f@redhat.com> <50e05a09-f620-6a5e-fbdf-04a0f8a6f6b8@redhat.com> Message-ID: <0756158f-8442-4c52-2be8-489cedce9161@redhat.com> Fixed the typo in error message. On 08/23/2016 12:15 PM, Tomas Krizek wrote: > In that case, the first version of the patch solves the issue. > > I'm attaching the patch once again, but it's the same as the one in > the original message. > > > On 08/23/2016 11:53 AM, Jan Cholasta wrote: >> On 22.8.2016 19:08, Tomas Krizek wrote: >>> I've attached the updated patch. Hopefully I didn't forget anything >>> else >>> this time. >>> >>> >>> On 08/22/2016 05:48 PM, Martin Basti wrote: >>>> >>>> On 22.08.2016 10:22, Tomas Krizek wrote: >>>>> >>>>> Seems like a good idea, I'm attaching the updated patch. Autofill >>>>> does work when the param is required. >>>>> >>>>> >>>>> On 08/19/2016 04:19 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 16.08.2016 17:35, Tomas Krizek wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the attached patch fixes an error message when user provides an >>>>>>> empty key while adding otp token. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/6200 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I'm curious why we don't fix it here: >>>>>> >>>>>> OTPTokenKey('ipatokenotpkey?', >>>>>> cli_name='key', >>>>>> label=_('Key'), >>>>>> doc=_('Token secret (Base32; default: random)'), >>>>>> default_from=lambda: os.urandom(KEY_LENGTH), >>>>>> autofill=True, >>>>>> flags=('no_display', 'no_update', 'no_search'), >>>>>> ), >>>>>> >>>>>> >>>>>> If OTPTokenKey is mandratory, it should be required param (autofill >>>>>> should work in this case too) >>>>>> >>>>>> Martin^2 >>>>> >>>>> -- >>>>> Tomas Krizek >>>> >>>> You changed API, you must regenerate API.txt (./makeapi) and increment >>>> minor version in VERSION file >>>> >>>> Option 'ipatokenotpkey?' in command 'otptoken_add/1' in API file >>>> not found >>>> Options count in otptoken_add of 22 doesn't match expected: 23 >>>> Option ipatokenotpkey of command otptoken_add in ipalib, not in API >>>> file: >>>> OTPTokenKey('ipatokenotpkey', autofill=True, cli_name='key') >> >> NACK, this is a backward incompatible change. >> >> AFAICT the option should remain optional, see the doc string: >> >> Token secret (Base32; default: random) >> ^^^^^^^^^^^^^^^ >> > > > -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tkrizek-0003-4-Validate-key-in-otptoken-add.patch Type: text/x-patch Size: 1045 bytes Desc: not available URL: From ofayans at redhat.com Wed Aug 24 11:58:01 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 24 Aug 2016 13:58:01 +0200 Subject: [Freeipa-devel] [Test][patch-0058] Fixed topology tests failures in CI In-Reply-To: <5beb66d0-62d4-1940-79be-4bcf16a140aa@redhat.com> References: <57AB735A.3000101@redhat.com> <57ADD39F.8050409@redhat.com> <5beb66d0-62d4-1940-79be-4bcf16a140aa@redhat.com> Message-ID: Hi Martin, Updated the test according to our discussion. There are 2 patches: the one related to the dynamic segment naming and the one that xfails one of the tests which fails due to trac ticket 6250. Please, disregard my previous patch On 08/12/2016 04:05 PM, Martin Basti wrote: > > > On 12.08.2016 15:48, Oleg Fayans wrote: >> Hi Martin, >> >> >> >> On 08/11/2016 10:05 AM, Martin Basti wrote: >>> >>> >>> On 10.08.2016 20:32, Oleg Fayans wrote: >>>> >>>> >>>> >>> Hello, >>> >>> before we jump into fixing tests, my question is: Was this planned >>> change and not reflected by test, or switched values are unwanted side >>> effect and thus bug for us? >> >> That's a marvelous question! The test used to pass, which means that >> at some point the convention of naming the segments must have changed. >> Is it a bug? I do not think so: the feature still works as expected. > > Ludwig, do you know details about this change, why positions of server > names are different than used to be in topology name? > >> >>> >>> Ticket contains almost no info, except a traceback and it says nothing. >>> Commit message says at least something. >>> >>> I'm not sure if this patch fixes that ticket, because traceback in test >>> shows error message that "removal of segment will disconnect topology", >>> but this patch only swap order of replica names in segment name. I would >>> expect that you should get different error, something like segment does >>> not exist. >> Which I do get in jenkins job N 37: "segment not found" >> >> In fact, the error in the issue is unrelated to the fix, you are right. > >> To tell the truth, I just put a random error from one of the jenkins >> topology testruns into the issue. > This is very good way how to report tickets: > * nobody knows what happened > * nobody can search in current tickets, what is wrong without proper > description > * developers cannot investigate issue, because there is even no name of > exact test in ticket, no steps to reproduce, nothing > * without proper tickets it is hard to backport patches correctly, if > patch fixes different issue than is reported > > I'm closing ticket as invalid, please follow > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html and file a new > proper ticket. > >> This particular error message was caused by a previous replica >> installation failure, which resulted in existing only one segment >> instead of three: >> master <-> replica1 >> instead of: >> master <-> replica1, >> master <-> replica2 >> replica1 <-> replica2 >> >> In fact the patch supplied fixes 2 tests at once: >> The first test tries to remove the unexisting segment master <-> >> replica2 and fails, the second test expects the line topology >> master <-> replica1 <-> replica2. >> It removes the connection between replica1 and replica2, expects the >> operation to fail but it does not because the connection between >> master and replica2 exists >> >> the output from the testrun with the patch applied: >> >> >> -bash-4.3$ ipa-run-tests test_integration/test_topology.py --pdb >> WARNING: Couldn't write lextab module 'pycparser.lextab'. [Errno 13] >> Permission denied: 'lextab.py' >> WARNING: yacc table file version is out of date >> WARNING: Couldn't create 'pycparser.yacctab'. [Errno 13] Permission >> denied: 'yacctab.py' >> ==================================================================================== >> test session starts >> ===================================================================================== >> >> platform linux2 -- Python 2.7.11, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 >> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >> plugins: sourceorder-0.5, multihost-1.0 >> collected 3 items >> >> test_integration/test_topology.py ... >> >> ================================================================================ >> 3 passed in 2156.82 seconds >> ================================================================================= >> >> > > I don't care about test output until there is no valid description of > problem, fixing test may just cover real issue. > Martin^2 >>> >>> Martin^2 >>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0059-Fixed-segment-naming-in-topology-tests.patch Type: text/x-patch Size: 4072 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0060-Xfailed-a-test-that-fails-due-to-6250.patch Type: text/x-patch Size: 2229 bytes Desc: not available URL: From ofayans at redhat.com Wed Aug 24 11:58:44 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 24 Aug 2016 13:58:44 +0200 Subject: [Freeipa-devel] [Test][patch-0058] Fixed topology tests failures in CI In-Reply-To: <5beb66d0-62d4-1940-79be-4bcf16a140aa@redhat.com> References: <57AB735A.3000101@redhat.com> <57ADD39F.8050409@redhat.com> <5beb66d0-62d4-1940-79be-4bcf16a140aa@redhat.com> Message-ID: <2c50265e-40fb-2243-5a19-72627060370f@redhat.com> And here is how the run looks like: $ ipa-run-tests test_integration/test_topology.py WARNING: Couldn't write lextab module 'pycparser.lextab'. [Errno 13] Permission denied: 'lextab.py' WARNING: yacc table file version is out of date WARNING: Couldn't create 'pycparser.yacctab'. [Errno 13] Permission denied: 'yacctab.py' ==================================================================================== test session starts ===================================================================================== platform linux2 -- Python 2.7.11, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini plugins: sourceorder-0.5, multihost-1.0 collected 3 items test_integration/test_topology.py ..x =========================================================================== 2 passed, 1 xfailed in 1558.66 seconds =========================================================================== On 08/12/2016 04:05 PM, Martin Basti wrote: > > > On 12.08.2016 15:48, Oleg Fayans wrote: >> Hi Martin, >> >> >> >> On 08/11/2016 10:05 AM, Martin Basti wrote: >>> >>> >>> On 10.08.2016 20:32, Oleg Fayans wrote: >>>> >>>> >>>> >>> Hello, >>> >>> before we jump into fixing tests, my question is: Was this planned >>> change and not reflected by test, or switched values are unwanted side >>> effect and thus bug for us? >> >> That's a marvelous question! The test used to pass, which means that >> at some point the convention of naming the segments must have changed. >> Is it a bug? I do not think so: the feature still works as expected. > > Ludwig, do you know details about this change, why positions of server > names are different than used to be in topology name? > >> >>> >>> Ticket contains almost no info, except a traceback and it says nothing. >>> Commit message says at least something. >>> >>> I'm not sure if this patch fixes that ticket, because traceback in test >>> shows error message that "removal of segment will disconnect topology", >>> but this patch only swap order of replica names in segment name. I would >>> expect that you should get different error, something like segment does >>> not exist. >> Which I do get in jenkins job N 37: "segment not found" >> >> In fact, the error in the issue is unrelated to the fix, you are right. > >> To tell the truth, I just put a random error from one of the jenkins >> topology testruns into the issue. > This is very good way how to report tickets: > * nobody knows what happened > * nobody can search in current tickets, what is wrong without proper > description > * developers cannot investigate issue, because there is even no name of > exact test in ticket, no steps to reproduce, nothing > * without proper tickets it is hard to backport patches correctly, if > patch fixes different issue than is reported > > I'm closing ticket as invalid, please follow > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html and file a new > proper ticket. > >> This particular error message was caused by a previous replica >> installation failure, which resulted in existing only one segment >> instead of three: >> master <-> replica1 >> instead of: >> master <-> replica1, >> master <-> replica2 >> replica1 <-> replica2 >> >> In fact the patch supplied fixes 2 tests at once: >> The first test tries to remove the unexisting segment master <-> >> replica2 and fails, the second test expects the line topology >> master <-> replica1 <-> replica2. >> It removes the connection between replica1 and replica2, expects the >> operation to fail but it does not because the connection between >> master and replica2 exists >> >> the output from the testrun with the patch applied: >> >> >> -bash-4.3$ ipa-run-tests test_integration/test_topology.py --pdb >> WARNING: Couldn't write lextab module 'pycparser.lextab'. [Errno 13] >> Permission denied: 'lextab.py' >> WARNING: yacc table file version is out of date >> WARNING: Couldn't create 'pycparser.yacctab'. [Errno 13] Permission >> denied: 'yacctab.py' >> ==================================================================================== >> test session starts >> ===================================================================================== >> >> platform linux2 -- Python 2.7.11, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 >> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >> plugins: sourceorder-0.5, multihost-1.0 >> collected 3 items >> >> test_integration/test_topology.py ... >> >> ================================================================================ >> 3 passed in 2156.82 seconds >> ================================================================================= >> >> > > I don't care about test output until there is no valid description of > problem, fixing test may just cover real issue. > Martin^2 >>> >>> Martin^2 >>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Wed Aug 24 12:21:54 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Aug 2016 14:21:54 +0200 Subject: [Freeipa-devel] [PATCH 0039][Tests] ID views tests do not recognize 'krbcanonicalname' attribute In-Reply-To: <0f465f11-9ac1-6a11-d000-a7d2831d77e5@redhat.com> References: <0f465f11-9ac1-6a11-d000-a7d2831d77e5@redhat.com> Message-ID: <4d34be4f-a0a7-f5c8-565e-4d533635053e@redhat.com> On 22.08.2016 15:46, Lenka Doudova wrote: > Hi, > > ID views tests still do not recognize 'krbcanonicalname' attribute - > fix attached. > > Lenka > > > ACK Pushed to master: 775c37bb812604496594524d8c6c7d936b4d3b15 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Aug 24 12:23:46 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 24 Aug 2016 14:23:46 +0200 Subject: [Freeipa-devel] [PATCH 0035] Remove Custodia server keys from LDAP In-Reply-To: <5326ea79-a4f9-17d7-639c-eb733a73ba5b@redhat.com> References: <0e0ece56-30cc-a2f5-2fd3-72370a498481@redhat.com> <8e8db094-ae33-76cc-0ab7-46784708d98b@redhat.com> <8bd66a1d-ccab-ebf1-5279-af2ae1bdcd34@redhat.com> <5326ea79-a4f9-17d7-639c-eb733a73ba5b@redhat.com> Message-ID: <33f76b92-5c77-ac6e-c3a1-140bcf78468e@redhat.com> On 08/24/2016 12:21 PM, Martin Basti wrote: > > > On 24.08.2016 11:25, Christian Heimes wrote: >> On 2016-08-23 12:42, Petr Vobornik wrote: >>> On 08/11/2016 04:13 PM, Martin Basti wrote: >>>> >>>> On 08.08.2016 16:10, Christian Heimes wrote: >>>>> The server-del plugin now removes the Custodia keys for encryption and >>>>> key signing from LDAP. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6015 >>>>> >>>>> >>>> ACK for master >>>> >>>> For 4.3, it requires new patch >>>> >>>> Martin >>>> >>> bump >> I haven't worked out a patch for 4.3. The server_del plugin in 4.3 is >> much simpler than in 4.4. It's not possible to hook the clean-up code to >> server_del like I did for 4.4. I would have to rewrite and redesign the >> patch completely which I neither have the time nor resources to at the >> moment. >> >> I vote for WONTFIX for 4.3. > +1 works for me > > Martin^2 >> >> Christian >> -- Petr Vobornik From mbasti at redhat.com Wed Aug 24 12:29:05 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Aug 2016 14:29:05 +0200 Subject: [Freeipa-devel] [PATCH 0035] Remove Custodia server keys from LDAP In-Reply-To: <33f76b92-5c77-ac6e-c3a1-140bcf78468e@redhat.com> References: <0e0ece56-30cc-a2f5-2fd3-72370a498481@redhat.com> <8e8db094-ae33-76cc-0ab7-46784708d98b@redhat.com> <8bd66a1d-ccab-ebf1-5279-af2ae1bdcd34@redhat.com> <5326ea79-a4f9-17d7-639c-eb733a73ba5b@redhat.com> <33f76b92-5c77-ac6e-c3a1-140bcf78468e@redhat.com> Message-ID: <29b162e9-1b88-b6ff-d4a2-eef48bc06ede@redhat.com> On 24.08.2016 14:23, Petr Vobornik wrote: > On 08/24/2016 12:21 PM, Martin Basti wrote: >> >> On 24.08.2016 11:25, Christian Heimes wrote: >>> On 2016-08-23 12:42, Petr Vobornik wrote: >>>> On 08/11/2016 04:13 PM, Martin Basti wrote: >>>>> On 08.08.2016 16:10, Christian Heimes wrote: >>>>>> The server-del plugin now removes the Custodia keys for encryption and >>>>>> key signing from LDAP. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6015 >>>>>> >>>>>> >>>>> ACK for master >>>>> >>>>> For 4.3, it requires new patch >>>>> >>>>> Martin >>>>> >>>> bump >>> I haven't worked out a patch for 4.3. The server_del plugin in 4.3 is >>> much simpler than in 4.4. It's not possible to hook the clean-up code to >>> server_del like I did for 4.4. I would have to rewrite and redesign the >>> patch completely which I neither have the time nor resources to at the >>> moment. >>> >>> I vote for WONTFIX for 4.3. >> +1 > works for me > >> Martin^2 >>> Christian >>> Pushed to master: c346a2d1d19dea645d5afbc9578e7d6049d36275 From mbasti at redhat.com Wed Aug 24 13:19:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Aug 2016 15:19:06 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add In-Reply-To: <0756158f-8442-4c52-2be8-489cedce9161@redhat.com> References: <6b7ecf18-952c-1c2e-5a35-744dc3fe434b@redhat.com> <07734948-b57d-79a2-23cf-97bd7aacf08f@redhat.com> <50e05a09-f620-6a5e-fbdf-04a0f8a6f6b8@redhat.com> <0756158f-8442-4c52-2be8-489cedce9161@redhat.com> Message-ID: On 24.08.2016 13:32, Tomas Krizek wrote: > Fixed the typo in error message. > > On 08/23/2016 12:15 PM, Tomas Krizek wrote: >> In that case, the first version of the patch solves the issue. >> >> I'm attaching the patch once again, but it's the same as the one in >> the original message. >> >> >> On 08/23/2016 11:53 AM, Jan Cholasta wrote: >>> On 22.8.2016 19:08, Tomas Krizek wrote: >>>> I've attached the updated patch. Hopefully I didn't forget anything >>>> else >>>> this time. >>>> >>>> >>>> On 08/22/2016 05:48 PM, Martin Basti wrote: >>>>> >>>>> On 22.08.2016 10:22, Tomas Krizek wrote: >>>>>> >>>>>> Seems like a good idea, I'm attaching the updated patch. Autofill >>>>>> does work when the param is required. >>>>>> >>>>>> >>>>>> On 08/19/2016 04:19 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 16.08.2016 17:35, Tomas Krizek wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> the attached patch fixes an error message when user provides an >>>>>>>> empty key while adding otp token. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/6200 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I'm curious why we don't fix it here: >>>>>>> >>>>>>> OTPTokenKey('ipatokenotpkey?', >>>>>>> cli_name='key', >>>>>>> label=_('Key'), >>>>>>> doc=_('Token secret (Base32; default: random)'), >>>>>>> default_from=lambda: os.urandom(KEY_LENGTH), >>>>>>> autofill=True, >>>>>>> flags=('no_display', 'no_update', 'no_search'), >>>>>>> ), >>>>>>> >>>>>>> >>>>>>> If OTPTokenKey is mandratory, it should be required param (autofill >>>>>>> should work in this case too) >>>>>>> >>>>>>> Martin^2 >>>>>> >>>>>> -- >>>>>> Tomas Krizek >>>>> >>>>> You changed API, you must regenerate API.txt (./makeapi) and >>>>> increment >>>>> minor version in VERSION file >>>>> >>>>> Option 'ipatokenotpkey?' in command 'otptoken_add/1' in API file >>>>> not found >>>>> Options count in otptoken_add of 22 doesn't match expected: 23 >>>>> Option ipatokenotpkey of command otptoken_add in ipalib, not in >>>>> API file: >>>>> OTPTokenKey('ipatokenotpkey', autofill=True, cli_name='key') >>> >>> NACK, this is a backward incompatible change. >>> >>> AFAICT the option should remain optional, see the doc string: >>> >>> Token secret (Base32; default: random) >>> ^^^^^^^^^^^^^^^ >>> >> >> >> > > -- > Tomas Krizek Pushed to master: 6f9a029bf5d33e6c8267cb330bd48033c5517188 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Aug 24 13:21:56 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Aug 2016 15:21:56 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Validate key in otptoken-add In-Reply-To: <0756158f-8442-4c52-2be8-489cedce9161@redhat.com> References: <6b7ecf18-952c-1c2e-5a35-744dc3fe434b@redhat.com> <07734948-b57d-79a2-23cf-97bd7aacf08f@redhat.com> <50e05a09-f620-6a5e-fbdf-04a0f8a6f6b8@redhat.com> <0756158f-8442-4c52-2be8-489cedce9161@redhat.com> Message-ID: On 24.08.2016 13:32, Tomas Krizek wrote: > Fixed the typo in error message. > > On 08/23/2016 12:15 PM, Tomas Krizek wrote: >> In that case, the first version of the patch solves the issue. >> >> I'm attaching the patch once again, but it's the same as the one in >> the original message. >> >> >> On 08/23/2016 11:53 AM, Jan Cholasta wrote: >>> On 22.8.2016 19:08, Tomas Krizek wrote: >>>> I've attached the updated patch. Hopefully I didn't forget anything >>>> else >>>> this time. >>>> >>>> >>>> On 08/22/2016 05:48 PM, Martin Basti wrote: >>>>> >>>>> On 22.08.2016 10:22, Tomas Krizek wrote: >>>>>> >>>>>> Seems like a good idea, I'm attaching the updated patch. Autofill >>>>>> does work when the param is required. >>>>>> >>>>>> >>>>>> On 08/19/2016 04:19 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 16.08.2016 17:35, Tomas Krizek wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> the attached patch fixes an error message when user provides an >>>>>>>> empty key while adding otp token. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/6200 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I'm curious why we don't fix it here: >>>>>>> >>>>>>> OTPTokenKey('ipatokenotpkey?', >>>>>>> cli_name='key', >>>>>>> label=_('Key'), >>>>>>> doc=_('Token secret (Base32; default: random)'), >>>>>>> default_from=lambda: os.urandom(KEY_LENGTH), >>>>>>> autofill=True, >>>>>>> flags=('no_display', 'no_update', 'no_search'), >>>>>>> ), >>>>>>> >>>>>>> >>>>>>> If OTPTokenKey is mandratory, it should be required param (autofill >>>>>>> should work in this case too) >>>>>>> >>>>>>> Martin^2 >>>>>> >>>>>> -- >>>>>> Tomas Krizek >>>>> >>>>> You changed API, you must regenerate API.txt (./makeapi) and >>>>> increment >>>>> minor version in VERSION file >>>>> >>>>> Option 'ipatokenotpkey?' in command 'otptoken_add/1' in API file >>>>> not found >>>>> Options count in otptoken_add of 22 doesn't match expected: 23 >>>>> Option ipatokenotpkey of command otptoken_add in ipalib, not in >>>>> API file: >>>>> OTPTokenKey('ipatokenotpkey', autofill=True, cli_name='key') >>> >>> NACK, this is a backward incompatible change. >>> >>> AFAICT the option should remain optional, see the doc string: >>> >>> Token secret (Base32; default: random) >>> ^^^^^^^^^^^^^^^ >>> >> >> >> > > -- > Tomas Krizek ACK Pushed to master: 6f9a029bf5d33e6c8267cb330bd48033c5517188 http://www.freeipa.org/page/Pull_request_on_Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From Peter.Marx at knorr-bremse.com Wed Aug 24 13:35:51 2016 From: Peter.Marx at knorr-bremse.com (Marx, Peter) Date: Wed, 24 Aug 2016 13:35:51 +0000 Subject: [Freeipa-devel] certmonger "failed to verify signature on server response" after receiving valid certificate In-Reply-To: <57BB0784.5010903@redhat.com> References: <2C720BBFE8885346B9A4377911BABE78868950A1@MUCS72046.corp.knorr-bremse.com> <57BB0784.5010903@redhat.com> Message-ID: <2C720BBFE8885346B9A4377911BABE7886896DFC@MUCS72046.corp.knorr-bremse.com> it depends on the depth of the cert chain if the verification fails or not. fails: RootCA-> SubCA-> end-entity works: RootCA-> SubCA-> SubSubCA->end-entity works: RootCA-> SubCA-> SubCA-> SubSubCA-> SubSubSubCA->end-entity when looking into the CA file, in cases where it works I see an extra entry ca_encryption_cert_pool=-----BEGIN CERTIFICATE----- MIIDHjCCAgagAwIBAgIIePjDfE7m7rMwDQYJKoZIhvcNAQEFBQAwGTEXMBUGA1UE .... EmkPKOf2v44U2E8ghQYKu8p4peuBqpInwOpsMj+x6zrlDw== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEQDCCAiigAwIBAgIIAWN7R90xPZYwDQYJKoZIhvcNAQELBQAwQjELMAkGA1UE BhMCREUxHDAaBgNVBAoME0tCIElULVNlcnZpY2VzIEdtYkgxFTATBgNVBAMMDGlD T00gUm9vdCBDQTAeFw0xNjA2MDkxNDI2MTFaFw0yNjA2MDkxNDI2MTFaMBkxFzAV BgNVBAMMDmlDT00gS3VuZGUxIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB .... -----END CERTIFICATE----- This entry is missing when the verification fails ! I got a valid cert in all test cases using jSCEP client and also in all certmonger test cases the server did generate and send the right cert. I suspect a bug in certmonger (scep-submit). Maybe related to handling the certificate chain. Peter -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Monday, August 22, 2016 4:09 PM To: Marx, Peter; freeipa-devel at redhat.com Subject: Re: [Freeipa-devel] certmonger "failed to verify signature on server response" after receiving valid certificate Marx, Peter wrote: > I'm testing with certmonger 0.78.6 (patched for the GETCACertChain > bug) against two EJBCA servers. For verification I a use a second SCEP > client called jSCEP. > > I started certmonger in debug mode with > "/usr/libexec/certmonger/certmonger-session -n -d 15" > > The CA file in /root/.config/certmonger/cas looks like this: > > id=Test_Sweden > > ca_aka=SCEP (certmonger 0.78.6) > > ca_is_default=0 > > ca_type=EXTERNAL > > ca_external_helper=/usr/libexec/certmonger/scep-submit -u > http://ejbca-test2.primekey.se:8080/ejbca/publicweb/apply/scep/mxrates > t/pkiclient.exe > -i "mx_kd3" > > ca_capabilities=POSTPKIOperation,Renewal,SHA-1 > > scep_ca_identifier=iCOM Kunde1 Schweden > > ca_encryption_cert=-----BEGIN CERTIFICATE----- > > > > -----END CERTIFICATE----- > > ca_encryption_issuer_cert=-----BEGIN CERTIFICATE----- > > > > -----END CERTIFICATE----- It looks to me that certmonger can't verify the signature of the returned PKCS#7 data. I'd double check the value of ca_encryption_issuer_cert. rob > > Issuing the request > > "getcert request -c Test_Sweden -v -d /tmp/nssdb -g 2048 -I husky201 > -p /tmp/pwd.txt -n husky201 -L abcd -N CN='husky201' -s" > > gives this log: > > 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for > 0x7fbe6b0c02e0. > > 2016-08-22 10:31:13 [22931] message > 0x7fbe6b0c02e0(method_call)->org.fedorahosted.certmonger:/org/fedoraho > sted/certmonger:org.fedorahosted.certmonger.add_request > > 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixUser serial 135 > > 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixProcessID serial > 136 > > 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b0aa690. > > 2016-08-22 10:31:13 [22931] Dequeuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b0aa690. > > 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for > 0x7fbe6b0c02e0. > > 2016-08-22 10:31:13 [22931] message > 0x7fbe6b0c02e0(method_return)->135->73 > > 2016-08-22 10:31:13 [22931] message > 0x7fbe6b0c02e0(method_return)->136->74 > > 2016-08-22 10:31:13 [22931] User ID 0 PID 23133 called > /org/fedorahosted/certmonger:org.fedorahosted.certmonger.add_request. > > 2016-08-22 10:31:13 [23135] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23135] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23135] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:31:13 [23135] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23135] Located the key 'husky201'. > > 2016-08-22 10:31:13 [23135] Converted private key 'husky201' to public key. > > 2016-08-22 10:31:13 [23135] Key is an RSA key. > > 2016-08-22 10:31:13 [23135] Key size is 2048. > > 2016-08-22 10:31:13 [23136] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23136] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23136] Found token 'NSS Generic Crypto Services'. > > 2016-08-22 10:31:13 [23136] Cert storage slot still needs user PIN to > be set. > > 2016-08-22 10:31:13 [23136] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23136] Error locating certificate. > > 2016-08-22 10:31:13 [22931] Request7('husky201') starts in state > 'NEWLY_ADDED' > > 2016-08-22 10:31:13 [22931] Request7('husky201') taking writing lock > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEWLY_ADDED_START_READING_KEYINFO' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Started Request7('husky201'). > > 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b09b4e0. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEWLY_ADDED_READING_KEYINFO' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on > traffic from 11. > > 2016-08-22 10:31:13 [22931] Dequeuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b09b4e0. > > 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for > 0x7fbe6b0c02e0. > > 2016-08-22 10:31:13 [22931] message > 0x7fbe6b0c02e0(method_call)->org.fedorahosted.certmonger:/org/fedoraho > sted/certmonger/requests/Request7:org.fedorahosted.certmonger.request. > get_nickname > > 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixUser serial 140 > > 2016-08-22 10:31:13 [22931] Pending GetConnectionUnixProcessID serial > 141 > > 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b0ae0a0. > > 2016-08-22 10:31:13 [22931] Dequeuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b0ae0a0. > > 2016-08-22 10:31:13 [22931] Handling D-Bus traffic (Read) on FD 8 for > 0x7fbe6b0c02e0. > > 2016-08-22 10:31:13 [22931] message > 0x7fbe6b0c02e0(method_return)->140->75 > > 2016-08-22 10:31:13 [22931] message > 0x7fbe6b0c02e0(method_return)->141->76 > > 2016-08-22 10:31:13 [22931] User ID 0 PID 23133 called > /org/fedorahosted/certmonger/requests/Request7:org.fedorahosted.certmonger.request.get_nickname. > > 2016-08-22 10:31:13 [22931] Queuing FD 8 for Read for > 0x7fbe6b0c02e0:0x7fbe6b09b4e0. > > 2016-08-22 10:31:13 [23137] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23137] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23137] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:31:13 [23137] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23137] Located the key 'husky201'. > > 2016-08-22 10:31:13 [23137] Converted private key 'husky201' to public key. > > 2016-08-22 10:31:13 [23137] Key is an RSA key. > > 2016-08-22 10:31:13 [23137] Key size is 2048. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEWLY_ADDED_START_READING_CERT' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEWLY_ADDED_READING_CERT' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on > traffic from 11. > > 2016-08-22 10:31:13 [23138] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23138] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23138] Found token 'NSS Generic Crypto Services'. > > 2016-08-22 10:31:13 [23138] Cert storage slot still needs user PIN to > be set. > > 2016-08-22 10:31:13 [23138] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23138] Error locating certificate. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEWLY_ADDED_DECIDING' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') releasing writing > lock > > 2016-08-22 10:31:13 [22931] Request7('husky201') has no certificate, > will attempt enrollment using already-present key > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'NEED_CSR' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'GENERATING_CSR' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on > traffic from 11. > > 2016-08-22 10:31:13 [23139] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23139] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23139] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:31:13 [23139] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23139] Located the key 'husky201'. > > 2016-08-22 10:31:13 [23139] Converted private key 'husky201' to public key. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'HAVE_CSR' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEED_TO_SUBMIT' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'SUBMITTING' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on > traffic from 15. > > 2016-08-22 10:31:13 [22931] Certificate submission attempt complete. > > 2016-08-22 10:31:13 [22931] Child status = 16. > > 2016-08-22 10:31:13 [22931] Child output: > > "Error reading request, expected PKCS7 data. > > " > > 2016-08-22 10:31:13 [22931] Error reading request, expected PKCS7 data. > > 2016-08-22 10:31:13 [22931] Certificate not (yet?) issued. > > 2016-08-22 10:31:13 [22931] Request7('husky201') goes to a CA over > SCEP, need to generate SCEP data. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEED_SCEP_DATA' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'GENERATING_SCEP_DATA' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on > traffic from 11. > > 2016-08-22 10:31:13 [23141] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23141] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23141] Generating dummy key. > > 2016-08-22 10:31:13 [23141] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:31:13 [23141] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:31:13 [23141] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:31:13 [23141] Found token 'NSS Certificate DB'. > > 2016-08-22 10:31:13 [23141] Located the key 'husky201'. > > 2016-08-22 10:31:13 [23141] Converted private key 'husky201' to public key. > > 2016-08-22 10:31:13 [23141] Server does not support DES3, using DES. > > 2016-08-22 10:31:13 [23141] Server does not support better digests, > using MD5. > > 2016-08-22 10:31:13 [23141] Generating PKCSREQ pkiMessage. > > 2016-08-22 10:31:13 [23141] Setting transaction ID > "46763632748922674693649122043315271915873922247404248201497767686509312971065". > > 2016-08-22 10:31:13 [23141] Setting message type "19". > > 2016-08-22 10:31:13 [23141] Setting sender nonce. > > 2016-08-22 10:31:13 [23141] Signed data. > > 2016-08-22 10:31:13 [23141] Generating GetCertInitial pkiMessage. > > 2016-08-22 10:31:13 [23141] Setting transaction ID > "46763632748922674693649122043315271915873922247404248201497767686509312971065". > > 2016-08-22 10:31:13 [23141] Setting message type "20". > > 2016-08-22 10:31:13 [23141] Setting sender nonce. > > 2016-08-22 10:31:13 [23141] Signed data. > > 2016-08-22 10:31:13 [23141] Signing using old key. > > 2016-08-22 10:31:13 [23141] Re-signing PKCSREQ message with old key. > > 2016-08-22 10:31:13 [23141] Re-signing GetCertInitial message with old key. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'HAVE_SCEP_DATA' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state > 'NEED_TO_SUBMIT' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') now. > > 2016-08-22 10:31:13 [22931] Request7('husky201') moved to state 'SUBMITTING' > > 2016-08-22 10:31:13 [22931] Will revisit Request7('husky201') on > traffic from 15. > > 2016-08-22 10:31:15 [22931] Certificate submission attempt complete. > > 2016-08-22 10:31:15 [22931] Child status = 3. > > 2016-08-22 10:31:15 [22931] Child output: > > "Error: failed to verify signature on server response. > > " > > 2016-08-22 10:31:15 [22931] Error: failed to verify signature on > server response. > > 2016-08-22 10:31:15 [22931] Certificate not (yet?) issued. > > 2016-08-22 10:31:15 [22931] Request7('husky201') moved to state > 'CA_UNREACHABLE' > > 2016-08-22 10:31:15 [22931] Will revisit Request7('husky201') in > 604800 seconds. > > I recorded the client server communication and can clearly see that > the server transmitted the certificate. > > When using jSCEP client I can successfully download certificates from > that server with e.g. > > $ openssl req -key test.key -new -days 30 -out test.pemreq -outform > PEM # end entity set to mx_pre2 > > $ java -jar target/jscepcli-1.0-SNAPSHOT-exe.jar --ca-identifier > mx_kd3 --challenge abcd --csr-file test.pemreq --dn "CN=mx_pre2" > --key-file test.key \ > > --url > http://ejbca-test2.primekey.se:8080/ejbca/publicweb/apply/scep/mxrates > t/pkiclient.exe > > With certmonger I can successfully get a cert using another CA with an > internal EJBCA server and this request: > > "getcert request -c Test_Sweden -v -d /tmp/nssdb -g 2048 -I husky100 > -p /tmp/pwd.txt -n husky100 -L abcd -N CN='husky100' -s" > > id=KBCA > > ca_aka=SCEP (certmonger 0.78.6) > > ca_is_default=0 > > ca_type=EXTERNAL > > ca_external_helper=/usr/libexec/certmonger/scep-submit -u > http://mucs70202.corp.knorr-bremse.com:8080/ejbca/publicweb/apply/scep > /pkiclient.exe > -i "iCOM%20Kunde1%20Dev%20SubCA" > > ca_capabilities=POSTPKIOperation,Renewal,SHA-1 > > scep_ca_identifier=KBCA > > ca_encryption_cert=-----BEGIN CERTIFICATE----- > > > > -----END CERTIFICATE----- > > ca_encryption_issuer_cert=-----BEGIN CERTIFICATE----- > > > > -----END CERTIFICATE----- > > *ca_encryption_cert_pool*=-----BEGIN CERTIFICATE----- > > > > -----END CERTIFICATE----- > > 2016-08-22 10:05:24 [21621] User ID 0 PID 22278 called > /org/fedorahosted/certmonger:org.fedorahosted.certmonger.add_request. > > 2016-08-22 10:05:24 [22280] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:24 [22280] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:24 [22280] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:24 [22280] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:24 [22280] Error locating a key. > > 2016-08-22 10:05:24 [22281] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:24 [22281] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:24 [22281] Found token 'NSS Generic Crypto Services'. > > 2016-08-22 10:05:24 [22281] Cert storage slot still needs user PIN to > be set. > > 2016-08-22 10:05:24 [22281] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:24 [22281] Error locating certificate. > > 2016-08-22 10:05:24 [21621] Request2('husky100') starts in state > 'NEWLY_ADDED' > > 2016-08-22 10:05:24 [21621] Request2('husky100') taking writing lock > > 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state > 'NEWLY_ADDED_START_READING_KEYINFO' > > 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:24 [21621] Started Request2('husky100'). > > 2016-08-22 10:05:24 [21621] Queuing FD 8 for Read for > 0x7fdf7bf25630:0x7fdf7bf33720. > > 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state > 'NEWLY_ADDED_READING_KEYINFO' > > 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') on > traffic from 11. > > 2016-08-22 10:05:24 [21621] Dequeuing FD 8 for Read for > 0x7fdf7bf25630:0x7fdf7bf33720. > > 2016-08-22 10:05:24 [21621] Handling D-Bus traffic (Read) on FD 8 for > 0x7fdf7bf25630. > > 2016-08-22 10:05:24 [21621] message > 0x7fdf7bf25630(method_call)->org.fedorahosted.certmonger:/org/fedoraho > sted/certmonger/requests/Request2:org.fedorahosted.certmonger.request. > get_nickname > > 2016-08-22 10:05:24 [21621] Pending GetConnectionUnixUser serial 1227 > > 2016-08-22 10:05:24 [21621] Pending GetConnectionUnixProcessID serial > 1228 > > 2016-08-22 10:05:24 [21621] Queuing FD 8 for Read for > 0x7fdf7bf25630:0x7fdf7bf2bc00. > > 2016-08-22 10:05:24 [21621] Dequeuing FD 8 for Read for > 0x7fdf7bf25630:0x7fdf7bf2bc00. > > 2016-08-22 10:05:24 [21621] Handling D-Bus traffic (Read) on FD 8 for > 0x7fdf7bf25630. > > 2016-08-22 10:05:24 [21621] message > 0x7fdf7bf25630(method_return)->1227->819 > > 2016-08-22 10:05:24 [21621] message > 0x7fdf7bf25630(method_return)->1228->820 > > 2016-08-22 10:05:24 [21621] User ID 0 PID 22278 called > /org/fedorahosted/certmonger/requests/Request2:org.fedorahosted.certmonger.request.get_nickname. > > 2016-08-22 10:05:24 [21621] Queuing FD 8 for Read for > 0x7fdf7bf25630:0x7fdf7bf33720. > > 2016-08-22 10:05:24 [22282] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:24 [22282] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:24 [22282] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:24 [22282] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:24 [22282] Error locating a key. > > 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state > 'NEWLY_ADDED_START_READING_CERT' > > 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:24 [21621] Request2('husky100') moved to state > 'NEWLY_ADDED_READING_CERT' > > 2016-08-22 10:05:24 [21621] Will revisit Request2('husky100') on > traffic from 11. > > 2016-08-22 10:05:25 [22283] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22283] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22283] Found token 'NSS Generic Crypto Services'. > > 2016-08-22 10:05:25 [22283] Cert storage slot still needs user PIN to > be set. > > 2016-08-22 10:05:25 [22283] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:25 [22283] Error locating certificate. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEWLY_ADDED_DECIDING' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') releasing writing > lock > > 2016-08-22 10:05:25 [21621] Request2('husky100') has no key or > certificate, will generate keys and attempt enrollment > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEED_KEY_PAIR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') taking writing lock > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'GENERATING_KEY_PAIR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on > traffic from 11. > > 2016-08-22 10:05:25 [22284] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22284] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22284] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:25 [22284] Generating key pair. > > 2016-08-22 10:05:25 [22284] Nickname "husky100" appears to be unused. > > 2016-08-22 10:05:25 [22284] Set nickname "husky100" on private key. > > 2016-08-22 10:05:25 [21621] Request2('husky100') releasing writing > lock > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'HAVE_KEY_PAIR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEED_KEYINFO' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'READING_KEYINFO' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on > traffic from 11. > > 2016-08-22 10:05:25 [22285] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22285] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22285] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:25 [22285] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:25 [22285] Located the key 'husky100'. > > 2016-08-22 10:05:25 [22285] Converted private key 'husky100' to public key. > > 2016-08-22 10:05:25 [22285] Key is an RSA key. > > 2016-08-22 10:05:25 [22285] Key size is 2048. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'HAVE_KEYINFO' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'NEED_CSR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'GENERATING_CSR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on > traffic from 11. > > 2016-08-22 10:05:25 [22286] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22286] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22286] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:25 [22286] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:25 [22286] Located the key 'husky100'. > > 2016-08-22 10:05:25 [22286] Converted private key 'husky100' to public key. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'HAVE_CSR' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEED_TO_SUBMIT' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'SUBMITTING' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on > traffic from 15. > > 2016-08-22 10:05:25 [21621] Certificate submission attempt complete. > > 2016-08-22 10:05:25 [21621] Child status = 16. > > 2016-08-22 10:05:25 [21621] Child output: > > "Error reading request, expected PKCS7 data. > > " > > 2016-08-22 10:05:25 [21621] Error reading request, expected PKCS7 data. > > 2016-08-22 10:05:25 [21621] Certificate not (yet?) issued. > > 2016-08-22 10:05:25 [21621] Request2('husky100') goes to a CA over > SCEP, need to generate SCEP data. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEED_SCEP_DATA' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'GENERATING_SCEP_DATA' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on > traffic from 11. > > 2016-08-22 10:05:25 [22288] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22288] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22288] Generating dummy key. > > 2016-08-22 10:05:25 [22288] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:25 [22288] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:25 [22288] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:25 [22288] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:25 [22288] Located the key 'husky100'. > > 2016-08-22 10:05:25 [22288] Converted private key 'husky100' to public key. > > 2016-08-22 10:05:25 [22288] Server does not support DES3, using DES. > > 2016-08-22 10:05:25 [22288] Server does not support better digests, > using MD5. > > 2016-08-22 10:05:25 [22288] Generating PKCSREQ pkiMessage. > > 2016-08-22 10:05:25 [22288] Setting transaction ID > "89399340103492129363376569585892061602695437784280139265051808388486717974760". > > 2016-08-22 10:05:25 [22288] Setting message type "19". > > 2016-08-22 10:05:25 [22288] Setting sender nonce. > > 2016-08-22 10:05:25 [22288] Signed data. > > 2016-08-22 10:05:25 [22288] Generating GetCertInitial pkiMessage. > > 2016-08-22 10:05:25 [22288] Setting transaction ID > "89399340103492129363376569585892061602695437784280139265051808388486717974760". > > 2016-08-22 10:05:25 [22288] Setting message type "20". > > 2016-08-22 10:05:25 [22288] Setting sender nonce. > > 2016-08-22 10:05:25 [22288] Signed data. > > 2016-08-22 10:05:25 [22288] Signing using old key. > > 2016-08-22 10:05:25 [22288] Re-signing PKCSREQ message with old key. > > 2016-08-22 10:05:25 [22288] Re-signing GetCertInitial message with old key. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'HAVE_SCEP_DATA' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state > 'NEED_TO_SUBMIT' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:25 [21621] Request2('husky100') moved to state 'SUBMITTING' > > 2016-08-22 10:05:25 [21621] Will revisit Request2('husky100') on > traffic from 15. > > 2016-08-22 10:05:26 [21621] Certificate submission attempt complete. > > 2016-08-22 10:05:26 [21621] Child status = 0. > > 2016-08-22 10:05:26 [21621] Child output: > > "-----BEGIN PKCS7----- > > MIAGCSqGSIb3DQEHA6CAMIACAQAxggFUMIIBUAIBADA4MBMxETAPBgNVBAMTCGh1 > > c2t5MTAwAiEAxaY7vcruKj5BOCTGw5wQBTpMC0GpLQ5rQJvfM6bjKOgwDQYJKoZI > > hvcNAQEBBQAEggEAF8VwCqiExnQyPQvdPV8vYFIvV0OGJ5AuyurIQQ0y3zeb6Jjc > > h4j6LilwV0BnUjdH9G2t4gGWUbbUVxciaXy0lgcZnO7C39ptc8tPfcfnD5gwRXdj > > jLjWTRa6IBhBvgZS6/tQ1uiWXygSnTVl9renZSBixKrnUSaRO5vHl4IsMWp4J8/p > > 39DY2zncvP/oq4bMKe5priZEjgbZkgFI9IuleQM80pzTHayWlChx2M5Cg5pDrBLc > > k0lZeVLQ6Vg5V3yRGSsXNrxkexYZkRFGQkZ/6gsLmj1nPPVGjhjbtoEGtQZGpXaW > > xD+nWyv2TUDge1OzIYj326scX3z3+YXcw2J23zCABgkqhkiG9w0BBwEwEQYFKw4D > > AgcECJgYnlIa2DxtoIAEggNgaTC2AhLM52T8guE2jr4YTK1UlcwDpN8yRJNRyuK7 > > vtDjx5aPx3+qTRJAOdeulV3pYK+3dpmddJoePGFpW/MaKBgAOpZVi/gk6LxnfKG4 > > l+gwPR7y3EyXXCyank553tceF08lPoPMfkRCe01le5EW2PKKH9y7JeqvVkxIjhI8 > > vaYKmARCLAtC4fXexjnjMxFKISctLTIJqqDfCn6T7h2j61jIAB4wABmTKjh1fwp5 > > +bR+enbCG33KY9taeDHvgAYl0XOi8IQ370dI57I72383RCcQdAa9qdMSnhquMyZL > > GS1zBnWrW9wMbMWkIRjR+1nGguS+6qBP4IekOuifoi/LHkSz/uOUuEi0cintRRy6 > > TsQEimydfIRfGrpcpaPCksHYUp/QZOSsQz9xAb/u6xMJMYRxKEw8q80xSniZP+dr > > HwfRThoJuxZcr3bpnRuEt2fYd1MgASeNTuZyLV4UJgdAZKAid74S0oi20OTSJyJE > > +GScqV/loZ4kJByE7fk3ZzCEWjOBhbzFzkoJ0vCxnRsq2eiyiTmTQvl4CM24q84f > > SNvUT3UE2NryGV8DSVuyUb0HX97x8Ii0l+pcciylWWy0W5qBhVlo5ns8aDfP4xqg > > blXv13hVIZPRs2KYFinK1ptOf2dBdYI8AFRx4eq85HGTd4J9yy5qIPjMfTVCNJz1 > > GLHFCIAQrClFehHvVrny0tO88B9/Xky9I6ReRPdz8kZ6GBCkTBS3I+4Km7uyo2Bd > > XE5XlBJhaVboApZIwLNaf24eqH/L9pG6O+BhzKQEFqDYmpIzWslIsBqtMPFWD5E/ > > x/v8O2Pj0b+Tmkky+VYv8gdEkOy6LPX2J4YH86PljJDEoSqhmSeeVFuGCbaRa60L > > NevoUzoQ3qCl/Brob7nDrOWeE1uJBWcDBs/CeFUvB0mfniIp0iDUOiTpWVm7drwv > > EMObPE+5SijzwFnj5HIgSpmHZUjFR9JcRfuG6E3u7BrDl1wS6U5lfb7Oqro2T6PF > > DB1+bL7NzCqF1nOYEDELOSrMxvk8/JQMxkBdrNx592FunoMEz8oAPbK5Lvt8oqE8 > > YcULZMb56Zp4S/L4P/8jV5KB9peXhxWhvU4qqXGeBBQSjggBxAURUZni5HaRrzv4 > > nUIyUuaf0fv3QY3tIi9hKaH8AAAAAAAAAAAAAA== > > -----END PKCS7----- > > " > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on > traffic from 11. > > 2016-08-22 10:05:26 [22292] Postprocessing output "-----BEGIN > PKCS7----- > > MIAGCSqGSIb3DQEHA6CAMIACAQAxggFUMIIBUAIBADA4MBMxETAPBgNVBAMTCGh1 > > c2t5MTAwAiEAxaY7vcruKj5BOCTGw5wQBTpMC0GpLQ5rQJvfM6bjKOgwDQYJKoZI > > hvcNAQEBBQAEggEAF8VwCqiExnQyPQvdPV8vYFIvV0OGJ5AuyurIQQ0y3zeb6Jjc > > h4j6LilwV0BnUjdH9G2t4gGWUbbUVxciaXy0lgcZnO7C39ptc8tPfcfnD5gwRXdj > > jLjWTRa6IBhBvgZS6/tQ1uiWXygSnTVl9renZSBixKrnUSaRO5vHl4IsMWp4J8/p > > 39DY2zncvP/oq4bMKe5priZEjgbZkgFI9IuleQM80pzTHayWlChx2M5Cg5pDrBLc > > k0lZeVLQ6Vg5V3yRGSsXNrxkexYZkRFGQkZ/6gsLmj1nPPVGjhjbtoEGtQZGpXaW > > xD+nWyv2TUDge1OzIYj326scX3z3+YXcw2J23zCABgkqhkiG9w0BBwEwEQYFKw4D > > AgcECJgYnlIa2DxtoIAEggNgaTC2AhLM52T8guE2jr4YTK1UlcwDpN8yRJNRyuK7 > > vtDjx5aPx3+qTRJAOdeulV3pYK+3dpmddJoePGFpW/MaKBgAOpZVi/gk6LxnfKG4 > > l+gwPR7y3EyXXCyank553tceF08lPoPMfkRCe01le5EW2PKKH9y7JeqvVkxIjhI8 > > vaYKmARCLAtC4fXexjnjMxFKISctLTIJqqDfCn6T7h2j61jIAB4wABmTKjh1fwp5 > > +bR+enbCG33KY9taeDHvgAYl0XOi8IQ370dI57I72383RCcQdAa9qdMSnhquMyZL > > GS1zBnWrW9wMbMWkIRjR+1nGguS+6qBP4IekOuifoi/LHkSz/uOUuEi0cintRRy6 > > TsQEimydfIRfGrpcpaPCksHYUp/QZOSsQz9xAb/u6xMJMYRxKEw8q80xSniZP+dr > > HwfRThoJuxZcr3bpnRuEt2fYd1MgASeNTuZyLV4UJgdAZKAid74S0oi20OTSJyJE > > +GScqV/loZ4kJByE7fk3ZzCEWjOBhbzFzkoJ0vCxnRsq2eiyiTmTQvl4CM24q84f > > SNvUT3UE2NryGV8DSVuyUb0HX97x8Ii0l+pcciylWWy0W5qBhVlo5ns8aDfP4xqg > > blXv13hVIZPRs2KYFinK1ptOf2dBdYI8AFRx4eq85HGTd4J9yy5qIPjMfTVCNJz1 > > GLHFCIAQrClFehHvVrny0tO88B9/Xky9I6ReRPdz8kZ6GBCkTBS3I+4Km7uyo2Bd > > XE5XlBJhaVboApZIwLNaf24eqH/L9pG6O+BhzKQEFqDYmpIzWslIsBqtMPFWD5E/ > > x/v8O2Pj0b+Tmkky+VYv8gdEkOy6LPX2J4YH86PljJDEoSqhmSeeVFuGCbaRa60L > > NevoUzoQ3qCl/Brob7nDrOWeE1uJBWcDBs/CeFUvB0mfniIp0iDUOiTpWVm7drwv > > EMObPE+5SijzwFnj5HIgSpmHZUjFR9JcRfuG6E3u7BrDl1wS6U5lfb7Oqro2T6PF > > DB1+bL7NzCqF1nOYEDELOSrMxvk8/JQMxkBdrNx592FunoMEz8oAPbK5Lvt8oqE8 > > YcULZMb56Zp4S/L4P/8jV5KB9peXhxWhvU4qqXGeBBQSjggBxAURUZni5HaRrzv4 > > nUIyUuaf0fv3QY3tIi9hKaH8AAAAAAAAAAAAAA== > > -----END PKCS7----- > > ". > > 2016-08-22 10:05:26 [22292] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:26 [22292] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:26 [22292] Skipping NSS internal slot (NSS Generic > Crypto Services). > > 2016-08-22 10:05:26 [22292] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] error:0D0680A8:asn1 encoding > routines:ASN1_CHECK_TLEN:wrong tag > > 2016-08-22 10:05:26 [22292] error:0D07803A:asn1 encoding > routines:ASN1_ITEM_EX_D2I:nested asn1 error > > 2016-08-22 10:05:26 [22292] error:0D0680A8:asn1 encoding > routines:ASN1_CHECK_TLEN:wrong tag > > 2016-08-22 10:05:26 [22292] error:0D07803A:asn1 encoding > routines:ASN1_ITEM_EX_D2I:nested asn1 error > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Error decrypting bulk key: SEC_ERROR_BAD_DATA. > > 2016-08-22 10:05:26 [22292] Succeeded in decrypting enveloped data. > > 2016-08-22 10:05:26 [22292] Succeeded in decrypting enveloped data. > > 2016-08-22 10:05:26 [21621] Certificate submission postprocessing complete. > > 2016-08-22 10:05:26 [21621] Child status = 0. > > 2016-08-22 10:05:26 [21621] Child output: > > "{"certificate":"-----BEGIN > CERTIFICATE-----\nMIIDKjCCAhKgAwIBAgIIBVULrGtczBowDQYJKoZIhvcNAQEFBQAwIDEeMBwGA1UE\nAwwVaUNPTSBLdW5kZTEgRGV2IFN1YkNBMB4XDTE2MDgyMjA3NTUyNloXDTI2MDYw\nOTE0MjYxMVowEzERMA8GA1UEAwwIaHVza3kxMDAwggEiMA0GCSqGSIb3DQEBAQUA\nA4IBDwAwggEKAoIBAQCwj6TZXwh2TD1UJuEc/LhjgUF91BJ4OOpjt2uOyfTsGaFO\nDykz0tEWyXRk7mkHQeqC/isVD0CYz6bhks2HwwqMAIc37eaz/uEIPQu4rz59gUMl\nVkh93YOtX2JlsQ0y0QPuwIGgb3Z1NX8MbhlE0GpLrb2vY8Y0TpBjwGpbagaMRPgz\nyP2v62jau9xn+72VTjOxNImJH/8V1UTDl1gt0lR2XH5dMeo+weVW8ZUvgDykhQDj\nq4V/trRW+556owhPv2ALBpuubp99d2rfPSdWnLg7JCtpIEIGq9KcEIfV1Bq/d4zb\n3PVrb1xZIb2vCOYyijUr8OCpgMslTM1WiKdIw9GTAgMBAAGjdTBzMAwGA1UdEwEB\n/wQCMAAwHwYDVR0jBBgwFoAUp+pgIuSdJoXPRmZ6unXbKtfB2NowEwYDVR0lBAww\nCgYIKwYBBQUHAwIwHQYDVR0OBBYEFCKFlaNB18Tf7Njwy/8I1aDPge3DMA4GA1Ud\nDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAho5avfYElYPaUxr9diXxG4aA\nVijNIiGXa6FmOwmMmR2h2UUqn11doNbkR+Zv4FFjMqdlWQh4aMLhn6Z0+ahSx3NY\nHG0saJfV88loRb+zC03yOyPIjEmFo4d2Vc+CsXAQ49ElHVKjqqC3JaMrma/EfMQ2\nW6Sc8x55smgPXjPLf8VytHdjH/ZeCDFbBYqs8CS0JbjP2! UppEjwWAv4 r8QH8VWuz\n97kxRpXFVTXb/gJUCxNqJRCU1aFTfO1L6x9BzfVKJX73nyAuQmZ+090PJIFCTTx/\nexdeoX0EBPeGmV7XjAO5GqGq+P6i3oeJ/Z8Kvug0XzlUSc55SMbc+z2B07GVIA==\n-----END > CERTIFICATE-----\n","key_checked":true} > > " > > 2016-08-22 10:05:26 [21621] Issued certificate is "-----BEGIN > CERTIFICATE----- > > MIIDKjCCAhKgAwIBAgIIBVULrGtczBowDQYJKoZIhvcNAQEFBQAwIDEeMBwGA1UE > > AwwVaUNPTSBLdW5kZTEgRGV2IFN1YkNBMB4XDTE2MDgyMjA3NTUyNloXDTI2MDYw > > OTE0MjYxMVowEzERMA8GA1UEAwwIaHVza3kxMDAwggEiMA0GCSqGSIb3DQEBAQUA > > A4IBDwAwggEKAoIBAQCwj6TZXwh2TD1UJuEc/LhjgUF91BJ4OOpjt2uOyfTsGaFO > > Dykz0tEWyXRk7mkHQeqC/isVD0CYz6bhks2HwwqMAIc37eaz/uEIPQu4rz59gUMl > > Vkh93YOtX2JlsQ0y0QPuwIGgb3Z1NX8MbhlE0GpLrb2vY8Y0TpBjwGpbagaMRPgz > > yP2v62jau9xn+72VTjOxNImJH/8V1UTDl1gt0lR2XH5dMeo+weVW8ZUvgDykhQDj > > q4V/trRW+556owhPv2ALBpuubp99d2rfPSdWnLg7JCtpIEIGq9KcEIfV1Bq/d4zb > > 3PVrb1xZIb2vCOYyijUr8OCpgMslTM1WiKdIw9GTAgMBAAGjdTBzMAwGA1UdEwEB > > /wQCMAAwHwYDVR0jBBgwFoAUp+pgIuSdJoXPRmZ6unXbKtfB2NowEwYDVR0lBAww > > CgYIKwYBBQUHAwIwHQYDVR0OBBYEFCKFlaNB18Tf7Njwy/8I1aDPge3DMA4GA1Ud > > DwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAho5avfYElYPaUxr9diXxG4aA > > VijNIiGXa6FmOwmMmR2h2UUqn11doNbkR+Zv4FFjMqdlWQh4aMLhn6Z0+ahSx3NY > > HG0saJfV88loRb+zC03yOyPIjEmFo4d2Vc+CsXAQ49ElHVKjqqC3JaMrma/EfMQ2 > > W6Sc8x55smgPXjPLf8VytHdjH/ZeCDFbBYqs8CS0JbjP2UppEjwWAv4r8QH8VWuz > > 97kxRpXFVTXb/gJUCxNqJRCU1aFTfO1L6x9BzfVKJX73nyAuQmZ+090PJIFCTTx/ > > exdeoX0EBPeGmV7XjAO5GqGq+P6i3oeJ/Z8Kvug0XzlUSc55SMbc+z2B07GVIA== > > -----END CERTIFICATE----- > > ". > > 2016-08-22 10:05:26 [21621] Certificate issued (0 chain certificates, > 0 roots). > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'NEED_TO_SAVE_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') taking writing lock > > 2016-08-22 10:05:26 [21621] No hooks set for pre-save command. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'START_SAVING_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'SAVING_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on > traffic from 11. > > 2016-08-22 10:05:26 [22293] No duplicate nickname entries. > > 2016-08-22 10:05:26 [22293] No duplicate subject name entries. > > 2016-08-22 10:05:26 [22293] Imported certificate "husky100", got > nickname "husky100". > > 2016-08-22 10:05:26 [22293] Removed name from old key. > > 2016-08-22 10:05:26 [22293] Error shutting down NSS. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'SAVED_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'NEED_TO_SAVE_CA_CERTS' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'START_SAVING_CA_CERTS' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'SAVING_CA_CERTS' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on > traffic from 11. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'NEED_TO_READ_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'READING_CERT' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on > traffic from 11. > > 2016-08-22 10:05:26 [22295] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:26 [22295] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:26 [22295] Found token 'NSS Generic Crypto Services'. > > 2016-08-22 10:05:26 [22295] Cert storage slot still needs user PIN to > be set. > > 2016-08-22 10:05:26 [22295] Found token 'NSS Certificate DB'. > > 2016-08-22 10:05:26 [22295] Located the certificate "husky100". > > 2016-08-22 10:05:26 [22295] Read value "0" from > "/proc/sys/crypto/fips_enabled". > > 2016-08-22 10:05:26 [22295] Not attempting to set NSS FIPS mode. > > 2016-08-22 10:05:26 [21621] No hooks set for post-save command. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'NEED_TO_NOTIFY_ISSUED_SAVED' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') now. > > 2016-08-22 10:05:26 [21621] Request2('husky100') releasing writing > lock > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state > 'NOTIFYING_ISSUED_SAVED' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') on > traffic from 11. > > 2016-08-22 10:05:26 [22296] 0x1d Certificate named "husky100" in token > "NSS Certificate DB" in database "/tmp/nssdb" issued by CA and saved. > > 2016-08-22 10:05:26 [21621] Request2('husky100') moved to state 'MONITORING' > > 2016-08-22 10:05:26 [21621] Will revisit Request2('husky100') soon. > > 2016-08-22 10:05:31 [21621] Will revisit Request2('husky100') in 86400 > seconds. > > Besides this "Error reading request, expected PKCS7 data" which always > shows up and "Error decrypting bulk key: SEC_ERROR_BAD_DATA" errors (?) > finally the cert is issued and stored into the nSS DB. > > Certificate: > > Data: > > Version: 3 (0x2) > > Serial Number: 8344117917752670949 (0x73cc4309839ebae5) > > Signature Algorithm: sha1WithRSAEncryption > > Issuer: CN=mx_kd3 > > Validity > > Not Before: Aug 19 16:03:29 2016 GMT > > Not After : Aug 2 15:23:36 2017 GMT > > Subject: CN=mx_pre2 > > Subject Public Key Info: > > Public Key Algorithm: rsaEncryption > > Public-Key: (2048 bit) > > Modulus: > > 00:89:01:fc:d4:a0:5c:df:8d:b6:f6:e3:49:8c:93: > > 77:7a:1e:26:34:4e:37:90:c3:6c:b0:e0:5d:a7:47: > > 8e:81:8f:d8:04:d5:c0:03:26:1a:a5:49:c8:82:98: > > 40:25:34:2e:43:c5:7d:cc:10:0e:b0:13:26:25:c0: > > 3d:87:15:fc:7f:90:6d:3d:2f:d6:ce:31:1f:af:38: > > 3f:8c:e9:fc:01:4c:a6:c5:3f:82:cb:c0:f8:8c:e7: > > 30:75:ba:68:b8:69:a6:6b:6c:04:a3:58:fb:b0:10: > > 94:4b:a2:f6:bd:24:f7:75:97:c0:f2:4e:ee:d9:df: > > 7b:61:8b:46:a9:d4:46:96:05:31:e5:60:87:3e:8d: > > 9b:8e:b2:f6:0f:03:1f:b7:49:1d:83:ec:9f:66:b1: > > f9:76:dd:dd:c5:b6:fa:52:5f:56:ce:2e:00:87:11: > > 90:6d:ba:c3:d7:fd:19:e0:64:c1:5d:0b:62:59:ad: > > 61:80:a7:76:d4:08:39:6b:2e:6f:05:68:c9:10:b4: > > 9f:3e:b9:d0:63:9f:7d:e1:a7:74:4f:f8:f4:17:34: > > f5:bf:ab:c6:bf:b9:48:80:59:ec:00:41:de:8b:46: > > 30:9d:8c:2b:d4:f3:2e:bd:39:e6:da:cd:d9:32:04: > > 55:04:29:26:66:0f:ac:ac:d2:bf:b1:19:56:62:0a: > > 56:69 > > Exponent: 65537 (0x10001) > > X509v3 extensions: > > X509v3 Subject Key Identifier: > > > D7:06:53:64:27:62:69:3B:ED:79:B2:6A:D8:94:DD:EE:B6:9C:51:44 > > X509v3 Basic Constraints: critical > > CA:FALSE > > X509v3 Authority Key Identifier: > > > keyid:8C:DB:52:66:8F:60:01:FA:58:8D:82:06:01:25:9C:2C:7D:D0:A0:14 > > X509v3 Key Usage: critical > > Digital Signature, Key Encipherment > > X509v3 Extended Key Usage: > > TLS Web Client Authentication > > Signature Algorithm: sha1WithRSAEncryption > > 45:a1:0c:9b:7b:20:31:0a:90:53:21:b8:d5:e2:05:0f:29:10: > > 77:d6:3a:44:38:9d:4a:d0:19:30:99:b9:41:0e:b1:4b:0e:c2: > > 35:36:ce:98:5f:0a:54:88:3b:91:d1:fb:df:e5:6f:57:f9:04: > > 0d:51:bf:c5:50:c3:c6:4d:88:a0:73:31:99:63:85:69:81:66: > > 93:5c:c3:bf:3f:ef:50:cc:db:de:fe:95:43:64:f0:2c:66:c1: > > f0:64:6f:8d:75:53:54:48:28:92:05:e1:21:a2:d6:fe:e3:1e: > > 5a:af:87:ba:45:06:39:47:5a:b8:df:1c:d8:cc:cf:6a:4a:ac: > > 08:92:7c:5b:08:9b:d5:0b:6d:49:33:c3:8f:a3:2c:50:4e:50: > > ae:d3:61:27:09:8c:de:c3:04:91:e0:f9:0e:aa:63:49:84:5e: > > cc:03:78:14:6e:cc:c3:5e:46:3b:56:6c:ae:20:7b:ce:51:8a: > > 78:eb:6b:4b:80:45:45:f3:3f:14:b6:d0:6a:99:d4:46:ad:d2: > > 0f:4d:99:4d:31:34:1f:4f:a3:19:92:45:8f:89:29:7e:4e:e7: > > 43:b2:15:4d:df:8a:66:70:c4:5d:b0:e3:d8:13:77:c2:51:98: > > 67:7d:b4:3c:95:71:54:05:06:1f:69:ae:fc:b1:00:b4:88:84: > > da:e0:85:ae > > subject= /CN=mx_pre2 > > issuer= /CN=mx_kd3 > > -----BEGIN PUBLIC KEY----- > > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiQH81KBc34229uNJjJN3 > > eh4mNE43kMNssOBdp0eOgY/YBNXAAyYapUnIgphAJTQuQ8V9zBAOsBMmJcA9hxX8 > > f5BtPS/WzjEfrzg/jOn8AUymxT+Cy8D4jOcwdbpouGmma2wEo1j7sBCUS6L2vST3 > > dZfA8k7u2d97YYtGqdRGlgUx5WCHPo2bjrL2DwMft0kdg+yfZrH5dt3dxbb6Ul9W > > zi4AhxGQbbrD1/0Z4GTBXQtiWa1hgKd21Ag5ay5vBWjJELSfPrnQY5994ad0T/j0 > > FzT1v6vGv7lIgFnsAEHei0YwnYwr1PMuvTnm2s3ZMgRVBCkmZg+srNK/sRlWYgpW > > aQIDAQAB > > -----END PUBLIC KEY----- > > SHA1 > Fingerprint=C3:B6:32:E9:70:E8:0F:98:A5:77:8E:96:13:5B:F8:40:63:37:29:7 > E > > So the question is why certmonger fails to verify signature on server > response depending on which server I try. > > What is included in the checks ? hostname of clients/servers? > > How can I debug this ? I'm not an experienced C programmer and was > just able to apply that GetCACertchain fix in scep.c and build > certmonger with that. > > Peter > > > automechanika InnoTrans IAA > automechanika > 13.09.-17.09.2016 > Messe Frankfurt > Hall 3.0 > Stand G98 + E91 InnoTrans > 20.09.-23.09.2016 > Messe Berlin > Hall 1.2b > Stand 104 + 210 IAA > 22.09.-29.09.2016 > Messe Hannover > Hall 17 > Stand A30 + D131 > > > Knorr-Bremse IT-Services GmbH > Sitz: M?nchen > Gesch?ftsf?hrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald > Schneider Registergericht M?nchen, HR B 167 268 > > This transmission is intended solely for the addressee and contains > confidential information. > If you are not the intended recipient, please immediately inform the > sender and delete the message and any attachments from your system. > Furthermore, please do not copy the message or disclose the contents > to anyone unless agreed otherwise. To the extent permitted by law we > shall in no way be liable for any damages, whatever their nature, > arising out of transmission failures, viruses, external influence, delays and the like. > > automechanika - 13.09.-17.09.2016 - Messe Frankfurt - Hall 3.0 - Stand G98 + E91 InnoTrans - 20.09.-23.09.2016 - Messe Berlin - Hall 1.2b - Stand 104 + 210 IAA - 22.09.-29.09.2016 - Messe Hannover - Hall 17 - Stand A30 + D131 Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. From gkaihoro at redhat.com Wed Aug 24 13:49:41 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Wed, 24 Aug 2016 09:49:41 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0036, 0037][Tests] Host/service tests do not recognize newly added attribute In-Reply-To: References: Message-ID: <1239313845.74075793.1472046581940.JavaMail.zimbra@redhat.com> Hello! [0036] ACK [0037] ACK Best regards, Ganna Kaihorodova Associate Software Quality Engineer ----- Original Message ----- From: "Lenka Doudova" To: "freeipa-devel" Sent: Monday, August 22, 2016 12:17:23 PM Subject: [Freeipa-devel] [PATCH 0036, 0037][Tests] Host/service tests do not recognize newly added attribute Hi, attached patches fix test fails occuring since patch for [1] was pushed. Ticket for tests: https://fedorahosted.org/freeipa/ticket/6240 Lenka [1] https://fedorahosted.org/freeipa/ticket/5764 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From freeipa-github-notification at redhat.com Wed Aug 24 13:50:12 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 15:50:12 +0200 Subject: [Freeipa-devel] [freeipa PR#13] Handled empty hostname in server-del command (+ack) In-Reply-To: References: Message-ID: Akasurde's pull request #13: "Handled empty hostname in server-del command" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/13 From freeipa-github-notification at redhat.com Wed Aug 24 13:51:25 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 15:51:25 +0200 Subject: [Freeipa-devel] [freeipa PR#13] Handled empty hostname in server-del command (+pushed) In-Reply-To: References: Message-ID: Akasurde's pull request #13: "Handled empty hostname in server-del command" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/13 From freeipa-github-notification at redhat.com Wed Aug 24 13:51:26 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 15:51:26 +0200 Subject: [Freeipa-devel] [freeipa PR#13] Handled empty hostname in server-del command (closed) In-Reply-To: References: Message-ID: Akasurde's pull request #13: "Handled empty hostname in server-del command" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/13 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/13/head:pr13 git checkout pr13 From freeipa-github-notification at redhat.com Wed Aug 24 13:51:28 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 15:51:28 +0200 Subject: [Freeipa-devel] [freeipa PR#13] Handled empty hostname in server-del command (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request Fixed upstream master: https://fedorahosted.org/freeipa/changeset/95a594af4c99255ea4da27e609cf41b79ca7ed91 See the full comment at https://github.com/freeipa/freeipa/pull/13#issuecomment-242071162 From mbasti at redhat.com Wed Aug 24 14:21:28 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Aug 2016 16:21:28 +0200 Subject: [Freeipa-devel] [PATCH 0036, 0037][Tests] Host/service tests do not recognize newly added attribute In-Reply-To: <1239313845.74075793.1472046581940.JavaMail.zimbra@redhat.com> References: <1239313845.74075793.1472046581940.JavaMail.zimbra@redhat.com> Message-ID: On 24.08.2016 15:49, Ganna Kaihorodova wrote: > Hello! > > [0036] ACK > [0037] ACK > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > ----- Original Message ----- > From: "Lenka Doudova" > To: "freeipa-devel" > Sent: Monday, August 22, 2016 12:17:23 PM > Subject: [Freeipa-devel] [PATCH 0036, 0037][Tests] Host/service tests do not recognize newly added attribute > > Hi, > > attached patches fix test fails occuring since patch for [1] was pushed. > > Ticket for tests: https://fedorahosted.org/freeipa/ticket/6240 > > Lenka > > > [1] https://fedorahosted.org/freeipa/ticket/5764 > > Pushed to master: 9021b649661ed135a4ee18ffe3728d661e6674a6 From ofayans at redhat.com Wed Aug 24 14:26:08 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 24 Aug 2016 16:26:08 +0200 Subject: [Freeipa-devel] [Test][patch-0061] Fixed error in teardown method of replica_promotion tests Message-ID: <48021659-0f1e-bd9a-3196-799104ecab80@redhat.com> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0061-Disabled-raiseonerr-in-kinit-call.patch Type: text/x-patch Size: 2109 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Aug 24 14:59:30 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 16:59:30 +0200 Subject: [Freeipa-devel] [freeipa PR#15] Secure permissions of Custodia server.keys (+ack) In-Reply-To: References: Message-ID: tiran's pull request #15: "Secure permissions of Custodia server.keys" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/15 From freeipa-github-notification at redhat.com Wed Aug 24 15:00:14 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 17:00:14 +0200 Subject: [Freeipa-devel] [freeipa PR#15] Secure permissions of Custodia server.keys (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d9ab0097e15618b0c614b3fdfa2ac4ea52b902c0 """ See the full comment at https://github.com/freeipa/freeipa/pull/15#issuecomment-242095453 From freeipa-github-notification at redhat.com Wed Aug 24 15:00:16 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 17:00:16 +0200 Subject: [Freeipa-devel] [freeipa PR#15] Secure permissions of Custodia server.keys (+pushed) In-Reply-To: References: Message-ID: tiran's pull request #15: "Secure permissions of Custodia server.keys" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/15 From freeipa-github-notification at redhat.com Wed Aug 24 15:00:17 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 17:00:17 +0200 Subject: [Freeipa-devel] [freeipa PR#15] Secure permissions of Custodia server.keys (closed) In-Reply-To: References: Message-ID: tiran's pull request #15: "Secure permissions of Custodia server.keys" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/15 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/15/head:pr15 git checkout pr15 From freeipa-github-notification at redhat.com Wed Aug 24 15:04:56 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 17:04:56 +0200 Subject: [Freeipa-devel] [freeipa PR#15] Secure permissions of Custodia server.keys (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream ipa-4-3: https://fedorahosted.org/freeipa/changeset/fc3b695b5969992d63fad12cdf9607b8e8a20aff """ See the full comment at https://github.com/freeipa/freeipa/pull/15#issuecomment-242097173 From freeipa-github-notification at redhat.com Wed Aug 24 15:19:27 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 17:19:27 +0200 Subject: [Freeipa-devel] [freeipa PR#16] Require httpd 2.4.6-31 with mod_proxy Unix socket support (+ack) In-Reply-To: References: Message-ID: tiran's pull request #16: "Require httpd 2.4.6-31 with mod_proxy Unix socket support" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/16 From freeipa-github-notification at redhat.com Wed Aug 24 15:22:58 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 17:22:58 +0200 Subject: [Freeipa-devel] [freeipa PR#16] Require httpd 2.4.6-31 with mod_proxy Unix socket support (+pushed) In-Reply-To: References: Message-ID: tiran's pull request #16: "Require httpd 2.4.6-31 with mod_proxy Unix socket support" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/16 From freeipa-github-notification at redhat.com Wed Aug 24 15:23:00 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 17:23:00 +0200 Subject: [Freeipa-devel] [freeipa PR#16] Require httpd 2.4.6-31 with mod_proxy Unix socket support (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/17bb9b9a9ba983020c66f4b83a5918be636ef3bd """ See the full comment at https://github.com/freeipa/freeipa/pull/16#issuecomment-242103959 From freeipa-github-notification at redhat.com Wed Aug 24 15:23:01 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 17:23:01 +0200 Subject: [Freeipa-devel] [freeipa PR#16] Require httpd 2.4.6-31 with mod_proxy Unix socket support (closed) In-Reply-To: References: Message-ID: tiran's pull request #16: "Require httpd 2.4.6-31 with mod_proxy Unix socket support" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/16 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/16/head:pr16 git checkout pr16 From freeipa-github-notification at redhat.com Wed Aug 24 15:26:44 2016 From: freeipa-github-notification at redhat.com (Akasurde) Date: Wed, 24 Aug 2016 17:26:44 +0200 Subject: [Freeipa-devel] [freeipa PR#13] Handled empty hostname in server-del command (comment) In-Reply-To: References: Message-ID: Akasurde commented on a pull request """ @mbasti-rh @stlaz Thanks for comments """ See the full comment at https://github.com/freeipa/freeipa/pull/13#issuecomment-242105659 From freeipa-github-notification at redhat.com Wed Aug 24 15:33:57 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 24 Aug 2016 17:33:57 +0200 Subject: [Freeipa-devel] [freeipa PR#16] Require httpd 2.4.6-31 with mod_proxy Unix socket support (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ I realized that we should use 2.4.7 in upstream specfile, to make porting of IPA easier """ See the full comment at https://github.com/freeipa/freeipa/pull/16#issuecomment-242108719 From mbasti at redhat.com Wed Aug 24 16:41:32 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Aug 2016 18:41:32 +0200 Subject: [Freeipa-devel] [PATCH] 0004 Fix ipa-server-install in pure IPv6 environment In-Reply-To: References: Message-ID: On 19.08.2016 14:09, Tomas Krizek wrote: > Hi, > > please review the attached patch. > > Make sure the hostname isn't resolved to link local IPv6(feXX:...) > during testing, which doesn't work (and isn't supposed to). > > > It did not work for me, pki-ca-spawn.log: /ca/getStatus (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',)) 2016-08-24 18:07:12 pkispawn : ERROR ....... server failed to restart 2016-08-24 18:07:12 pkispawn : DEBUG ....... Error Type: Exception 2016-08-24 18:07:12 pkispawn : DEBUG ....... Error Message: server failed to restart 2016-08-24 18:07:12 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 528, in main scriptlet.spawn(deployer) File "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", line 375, in spawn raise Exception("server failed to restart") journalctl: Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: Java virtual machine used: /usr/lib/jvm/jre-1.8.0-openjdk/bin/java Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: classpath used: /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.jar Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: main class used: org.apache.catalina.startup.Bootstrap Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: flags used: -DRESTEASY_LIB=/usr/share/java/resteasy -Djava.library.path=/usr/lib64/nuxwdog-jni Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: options used: -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pk Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: arguments used: stop Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: Aug 24, 2016 6:06:22 PM org.apache.catalina.startup.Catalina stopServer Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: SEVERE: Catalina.stop: Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: java.net.SocketException: Network is unreachable Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at java.net.PlainSocketImpl.socketConnect(Native Method) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at java.net.Socket.connect(Socket.java:589) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at java.net.Socket.connect(Socket.java:538) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at java.net.Socket.(Socket.java:434) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at java.net.Socket.(Socket.java:211) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:450) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at java.lang.reflect.Method.invoke(Method.java:498) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:400) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com server[58257]: at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:487) Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com systemd[1]: pki-tomcatd at pki-tomcat.service: Control process exited, code=exited status=1 Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com systemd[1]: pki-tomcatd at pki-tomcat.service: Unit entered failed state. Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com systemd[1]: pki-tomcatd at pki-tomcat.service: Failed with result 'exit-code'. ip a: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens3: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:1a:4a:23:14:a8 brd ff:ff:ff:ff:ff:ff inet6 2620:52:0:224e:21a:4aff:fe23:14a8/64 scope global noprefixroute dynamic valid_lft 2591653sec preferred_lft 604453sec inet6 fe80::21a:4aff:fe23:14a8/64 scope link valid_lft forever preferred_lft forever I removed myhostname from nsswitch Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Wed Aug 24 17:01:34 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 24 Aug 2016 11:01:34 -0600 Subject: [Freeipa-devel] Karma Requests for pki-core-10.3.5-3 Message-ID: *The following updated candidate builds of pki-core 10.3.5 on Fedora 24, 25, and 26 (rawhide) consist of the following:* * *Fedora 24* o *pki-core-10.3.5-3.fc24 * * *Fedora 25* o *pki-core-10.3.5-3.fc25 * * *Fedora 26* o *pki-core-10.3.5-3.fc26 * *Additionally, the CentOS 7 COPR EPEL Builds of Dogtag 10.3.3 were also updated: * * https://copr.fedorainfracloud.org/coprs/g/pki/10.3.3/repo/epel-7/group_pki-10.3.3-epel-7.repo [group_pki-10.3.3] name=Copr repo for 10.3.3 owned by @pki baseurl=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.3/epel-7-$basearch/ skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.3/pubkey.gpg enabled=1 enabled_metadata=1 *These builds address the following PKI tickets: * * PKI TRAC Ticket #690 - pki-tools man pages --- CMCEnroll * PKI TRAC Ticket #833 - pki user-mod fullName="" gives an error message "PKIException: LDAP error (21): error result" * PKI TRAC Ticket #2429 - [RFE] TPS UI: profile property needs to be added one by one can we add in bulk * PKI TRAC Ticket #2431 - Errors noticed during ipa server upgrade. * PKI TRAC Ticket #2432 - Kra-selftest behavior is not as expected * PKI TRAC Ticket #2436 - Dogtag 10.3.6: Miscellaneous Enhancements o include JSS cert validation error message in selftest log o add debug messages to ConfigurationUtils.handleCerts() o apply RFC 7468 Headers/Trailers to PKI tools * PKI TRAC Ticket #2437 - TPS UI: while adding certs for users from TPSUI pem format with/without header works while pkcs7 with header is not allowed * PKI TRAC Ticket #2440 - Optional CA signing CSR for migration *Please provide Karma for the following builds: * * *Fedora 24* o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-4d226a5f7e pki-core-10.3.5-1.fc24 + resteasy-3.0.17-3.fc24 * + *IMPORTANT: This combination build MUST be pushed first since pki-core-10.3.5-3.fc24 DEPENDS upon resteasy-3.0.17!!! * o *https://bodhi.fedoraproject.org/updates/pki-core-10.3.5-3.fc24 pki-core-10.3.5-3.fc24 * * *Fedora 25* o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-456eb9f4b7 pki-core-10.3.5-3.fc25 * * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Thu Aug 25 05:37:23 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Thu, 25 Aug 2016 07:37:23 +0200 Subject: [Freeipa-devel] [freeipa PR#17] Tests: Random issuer certificate can be added to a service (opened) In-Reply-To: References: Message-ID: mirielka's pull request #17: "Tests: Random issuer certificate can be added to a service" was opened PR body: """ Changing negative test case that verified that a certificate with different than expected issuer cannot be added to a service to a positive one that verifies that this operation now proceeds successfully. Corresponds to changes made in scope of https://fedorahosted.org/freeipa/ticket/4559 implementation. https://fedorahosted.org/freeipa/ticket/6258 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/17 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/17/head:pr17 git checkout pr17 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-17.patch URL: From freeipa-github-notification at redhat.com Thu Aug 25 07:18:27 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Thu, 25 Aug 2016 09:18:27 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (opened) In-Reply-To: References: Message-ID: ofayans's pull request #18: "Fixed incorrect sequence of method calls in tasks.py" was opened PR body: """ https://fedorahosted.org/freeipa/ticket/6255 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/18 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/18/head:pr18 git checkout pr18 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-18.patch URL: From mbasti at redhat.com Thu Aug 25 08:21:34 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Aug 2016 10:21:34 +0200 Subject: [Freeipa-devel] [PATCH] 0004 Fix ipa-server-install in pure IPv6 environment In-Reply-To: References: Message-ID: <76f421b0-8ab6-ed86-79b1-c029f51f6e4c@redhat.com> On 24.08.2016 18:41, Martin Basti wrote: > > > > On 19.08.2016 14:09, Tomas Krizek wrote: >> Hi, >> >> please review the attached patch. >> >> Make sure the hostname isn't resolved to link local IPv6(feXX:...) >> during testing, which doesn't work (and isn't supposed to). >> >> >> > It did not work for me, > > pki-ca-spawn.log: > /ca/getStatus (Caused by > NewConnectionError(' object at 0x7f3d35854310>: Failed to establish a new connection: > [Errno 111] Connection refused',)) > 2016-08-24 18:07:12 pkispawn : ERROR ....... server failed to > restart > 2016-08-24 18:07:12 pkispawn : DEBUG ....... Error Type: Exception > 2016-08-24 18:07:12 pkispawn : DEBUG ....... Error Message: > server failed to restart > 2016-08-24 18:07:12 pkispawn : DEBUG ....... File > "/usr/sbin/pkispawn", line 528, in main > scriptlet.spawn(deployer) > File > "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", > line 375, in spawn > raise Exception("server failed to restart") > > > journalctl: > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: Java virtual machine used: > /usr/lib/jvm/jre-1.8.0-openjdk/bin/java > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: classpath used: > /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.jar > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: main class used: org.apache.catalina.startup.Bootstrap > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: flags used: -DRESTEASY_LIB=/usr/share/java/resteasy > -Djava.library.path=/usr/lib64/nuxwdog-jni > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: options used: -Dcatalina.base=/var/lib/pki/pki-tomcat > -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= > -Djava.io.tmpdir=/var/lib/pk > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: arguments used: stop > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: Aug 24, 2016 6:06:22 PM > org.apache.catalina.startup.Catalina stopServer > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: SEVERE: Catalina.stop: > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: java.net.SocketException: Network is unreachable > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at > java.net.PlainSocketImpl.socketConnect(Native Method) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at > java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at java.net.Socket.connect(Socket.java:589) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at java.net.Socket.connect(Socket.java:538) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at java.net.Socket.(Socket.java:434) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at java.net.Socket.(Socket.java:211) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at > org.apache.catalina.startup.Catalina.stopServer(Catalina.java:450) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at java.lang.reflect.Method.invoke(Method.java:498) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at > org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:400) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com > server[58257]: at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:487) > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com systemd[1]: > pki-tomcatd at pki-tomcat.service: Control process exited, code=exited > status=1 > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com systemd[1]: > pki-tomcatd at pki-tomcat.service: Unit entered failed state. > Aug 24 18:06:22 vm-058-188.abc.idm.lab.eng.brq.redhat.com systemd[1]: > pki-tomcatd at pki-tomcat.service: Failed with result 'exit-code'. > > ip a: > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > group default qlen 1 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: ens3: mtu 1500 qdisc fq_codel > state UP group default qlen 1000 > link/ether 00:1a:4a:23:14:a8 brd ff:ff:ff:ff:ff:ff > inet6 2620:52:0:224e:21a:4aff:fe23:14a8/64 scope global > noprefixroute dynamic > valid_lft 2591653sec preferred_lft 604453sec > inet6 fe80::21a:4aff:fe23:14a8/64 scope link > valid_lft forever preferred_lft forever > > > I removed myhostname from nsswitch > > Martin^2 > > It looks that this was caused by some misconfiguration on my machine. ACK Pushed to master: fa3b3193fabcaa37c2ba9865089fcfc06939c77f -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Thu Aug 25 08:25:23 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 25 Aug 2016 18:25:23 +1000 Subject: [Freeipa-devel] [PATCH] 0101 Add ca-disable and ca-enable commands Message-ID: <20160825082523.GM3877@dhcp-40-8.bne.redhat.com> Hi team, The attached patch fixes https://fedorahosted.org/freeipa/ticket/6257. The behaviour of cert-request when the CA is disabled is not very nice (it reports a server error from Dogtag). The Dogtag REST interface gives much better errors so I plan to move to it in a later change (which will also address https://fedorahosted.org/freeipa/ticket/3473, in part). Thanks, Fraser -------------- next part -------------- From 1d99777c2145d33278d2b1d8a4e8a2d1341c8e4d Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 25 Aug 2016 17:00:01 +1000 Subject: [PATCH] Add ca-disable and ca-enable commands We soon plan to revoke certificates upon lightweight CA deletion. This makes it important to provide a way to prevent a CA from issuing certificates whilst not deleting and revoking it, and continuing to allow management of issued certs. This commit adds the ca-disable and ca-enable commands. Fixes: https://fedorahosted.org/freeipa/ticket/6257 --- API.txt | 16 ++++++++++++ VERSION | 4 +-- ipaserver/plugins/ca.py | 62 +++++++++++++++++++++++++++++++++++++++++++-- ipaserver/plugins/dogtag.py | 6 +++++ 4 files changed, 84 insertions(+), 4 deletions(-) diff --git a/API.txt b/API.txt index 5b83bfbd0b457b77e0522ab7d83abfae4df3ebe9..27b64ee143fa4f5f55c1b8a32446f004a8e3bb22 100644 --- a/API.txt +++ b/API.txt @@ -465,6 +465,20 @@ option: Str('version?') output: Output('result', type=[]) output: Output('summary', type=[, ]) output: ListOfPrimaryKeys('value') +command: ca_disable/1 +args: 1,1,3 +arg: Str('cn', cli_name='name') +option: Str('version?') +output: Output('result', type=[]) +output: Output('summary', type=[, ]) +output: PrimaryKey('value') +command: ca_enable/1 +args: 1,1,3 +arg: Str('cn', cli_name='name') +option: Str('version?') +output: Output('result', type=[]) +output: Output('summary', type=[, ]) +output: PrimaryKey('value') command: ca_find/1 args: 1,11,4 arg: Str('criteria?') @@ -6249,6 +6263,8 @@ default: batch/1 default: ca/1 default: ca_add/1 default: ca_del/1 +default: ca_disable/1 +default: ca_enable/1 default: ca_find/1 default: ca_is_enabled/1 default: ca_mod/1 diff --git a/VERSION b/VERSION index a8b89ed305bcfdf2990a7400d005a68d734fa7e8..8cc8b11c7c3e985ab53279b27a4701021e4271ba 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=212 -# Last change: ab: service: add flag to allow S4U2Self +IPA_API_VERSION_MINOR=213 +# Last change: ftweedal: add ca-disable and ca-enable commands diff --git a/ipaserver/plugins/ca.py b/ipaserver/plugins/ca.py index 966ae2b1bdb4bb0207dfa58f0e9c951bc930f766..93c48722720e8509c2d096d66f9f2bd1c5c631d8 100644 --- a/ipaserver/plugins/ca.py +++ b/ipaserver/plugins/ca.py @@ -2,12 +2,12 @@ # Copyright (C) 2016 FreeIPA Contributors see COPYING for license # -from ipalib import api, errors, DNParam, Str +from ipalib import api, errors, output, DNParam, Str from ipalib.constants import IPA_CA_CN from ipalib.plugable import Registry from ipaserver.plugins.baseldap import ( LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, - LDAPUpdate, LDAPRetrieve) + LDAPUpdate, LDAPRetrieve, LDAPQuery, pkey_to_value) from ipaserver.plugins.cert import ca_enabled_check from ipalib import _, ngettext @@ -18,6 +18,14 @@ Manage Certificate Authorities Subordinate Certificate Authorities (Sub-CAs) can be added for scoped issuance of X.509 certificates. +CAs are enabled on creation, but their use is subject to CA ACLs unless the +operator has permission to bypass CA ACLs. + +All CAs except the 'IPA' CA can be disabled or re-enabled. Disabling a CA +prevents it from issuing certificates but does not affect the validity of its +certificate. + + EXAMPLES: Create new CA, subordinate to the IPA CA. @@ -25,6 +33,10 @@ EXAMPLES: ipa ca-add puppet --desc "Puppet" \\ --subject "CN=Puppet CA,O=EXAMPLE.COM" + Disable a CA. + + ipa ca-disable puppet + """) @@ -222,3 +234,49 @@ class ca_mod(LDAPUpdate): reason=u'IPA CA cannot be renamed') return dn + + + at register() +class ca_disable(LDAPQuery): + __doc__ = _('Disable a CA.') + + msg_summary = _('Disabled CA "%(value)s"') + has_output = output.standard_value + + def execute(self, cn, **options): + ca_enabled_check() + + if cn == IPA_CA_CN: + raise errors.ProtectedEntryError( + label=_("CA"), + key=cn, + reason=_("IPA CA cannot be disabled")) + + ca_id = self.api.Command.ca_show(cn)['result']['ipacaid'][0] + with self.api.Backend.ra_lightweight_ca as ca_api: + ca_api.disable_ca(ca_id) + + return dict( + result=True, + value=pkey_to_value(cn, options), + ) + + + at register() +class ca_enable(LDAPQuery): + __doc__ = _('Enable a CA.') + + msg_summary = _('Enabled CA "%(value)s"') + has_output = output.standard_value + + def execute(self, cn, **options): + ca_enabled_check() + + ca_id = self.api.Command.ca_show(cn)['result']['ipacaid'][0] + with self.api.Backend.ra_lightweight_ca as ca_api: + ca_api.enable_ca(ca_id) + + return dict( + result=True, + value=pkey_to_value(cn, options), + ) diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index aef1e888eb1b6c273c1fd12cbf4912407f8f8132..01e5f1383ee135696a8e968793863ce964025094 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -2211,5 +2211,11 @@ class ra_lightweight_ca(RestClient): headers={'Accept': 'application/json'}, ) + def enable_ca(self, ca_id): + self._ssldo( + 'POST', ca_id + '/enable', + headers={'Accept': 'application/json'}, + ) + def delete_ca(self, ca_id): self._ssldo('DELETE', ca_id) -- 2.5.5 From abokovoy at redhat.com Thu Aug 25 08:32:10 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 25 Aug 2016 11:32:10 +0300 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <57BC4CE0.1020505@redhat.com> References: <57A9BD64.5050308@redhat.com> <20160809113803.2jehpfuxnrg4wozr@redhat.com> <57AACDD9.7070102@redhat.com> <20160810070337.kt4auntwnvznvplb@redhat.com> <20160810105131.74jbejwx5lbv54g6@redhat.com> <57AB3C11.9030008@redhat.com> <57AB47D4.5030400@redhat.com> <2d9299fd-1a50-6d2c-c65c-95cf7737033e@redhat.com> <57BC4CE0.1020505@redhat.com> Message-ID: <20160825083210.eqnpsg4jeoogvnra@redhat.com> On Tue, 23 Aug 2016, thierry bordaz wrote: >>>acceptance is now completed (successfully). ACK >>> >>bump >> >>so ACKed ab's 213-1 fixes https://fedorahosted.org/freeipa/ticket/6138 ? >> >Yes that is my understanding. patch 213-1 fixes #6138. >I verified that lookup of UPN entries does return the domain. But did >not know how to check that entries with multiple uid values only >returns the first value. Can we push 0213-1? -- / Alexander Bokovoy From mbasti at redhat.com Thu Aug 25 08:35:35 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Aug 2016 10:35:35 +0200 Subject: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map In-Reply-To: <20160825083210.eqnpsg4jeoogvnra@redhat.com> References: <57A9BD64.5050308@redhat.com> <20160809113803.2jehpfuxnrg4wozr@redhat.com> <57AACDD9.7070102@redhat.com> <20160810070337.kt4auntwnvznvplb@redhat.com> <20160810105131.74jbejwx5lbv54g6@redhat.com> <57AB3C11.9030008@redhat.com> <57AB47D4.5030400@redhat.com> <2d9299fd-1a50-6d2c-c65c-95cf7737033e@redhat.com> <57BC4CE0.1020505@redhat.com> <20160825083210.eqnpsg4jeoogvnra@redhat.com> Message-ID: <1bf38a14-37d4-f126-159c-f70199136130@redhat.com> On 25.08.2016 10:32, Alexander Bokovoy wrote: > On Tue, 23 Aug 2016, thierry bordaz wrote: >>>> acceptance is now completed (successfully). ACK >>>> >>> bump >>> >>> so ACKed ab's 213-1 fixes >>> https://fedorahosted.org/freeipa/ticket/6138 ? >>> >> Yes that is my understanding. patch 213-1 fixes #6138. >> I verified that lookup of UPN entries does return the domain. But did >> not know how to check that entries with multiple uid values only >> returns the first value. > Can we push 0213-1? Pushed to master: fab1f798ed6dfdb0b7de7c4fc4fe353f1d97177b From rajat.linux at gmail.com Thu Aug 25 09:13:03 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Thu, 25 Aug 2016 11:13:03 +0200 Subject: [Freeipa-devel] pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ilt-gif-ipa01.ipa.preprod.local user=aduser@corp.addomain.com In-Reply-To: References: <20160816124614.dnoqxpzw6gsvblo6@redhat.com> Message-ID: I am getting bellow menage in logs. when i trying to check the status for sssd service i am getting *Cannot find KDC for realm "ADDOMAIN.COM " *at the end #systemctl status sssd ? sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/sssd.service.d ??journal.conf Active: active (running) since Thu 2016-08-25 09:36:26 CEST; 8min ago Main PID: 11031 (sssd) CGroup: /system.slice/sssd.service ??11031 /usr/sbin/sssd -D -f ??11032 /usr/libexec/sssd/sssd_be --domain ipa.preprod.local --uid 0 --gid 0 --debug-to-files ??11033 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files ??11034 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --debug-to-files ??11035 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files ??11036 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --debug-to-files ??11037 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --debug-to-files Aug 25 09:36:26 ilt-gif-ipa02.ipa.preprod.local sssd[ssh][11036]: Starting up Aug 25 09:36:26 ilt-gif-ipa02.ipa.preprod.local sssd[pac][11037]: Starting up Aug 25 09:36:26 ilt-gif-ipa02.ipa.preprod.local sssd_nss[11033]: chown failed for [sssd_nss]: [2] Aug 25 09:36:26 ilt-gif-ipa02.ipa.preprod.local sssd[nss][11033]: Starting up Aug 25 09:36:26 ilt-gif-ipa02.ipa.preprod.local sssd_be[11032]: GSSAPI client step 1 Aug 25 09:36:26 ilt-gif-ipa02.ipa.preprod.local sssd_be[11032]: GSSAPI client step 1 Aug 25 09:36:26 ilt-gif-ipa02.ipa.preprod.local systemd[1]: Started System Security Services Daemon. Aug 25 09:36:26 ilt-gif-ipa02.ipa.preprod.local sssd_be[11032]: GSSAPI client step 1 Aug 25 09:36:27 ilt-gif-ipa02.ipa.preprod.local sssd_be[11032]: GSSAPI client step 2 Aug 25 09:36:37 ilt-gif-ipa02.ipa.preprod.local [sssd[krb5_child[11262]]][11262]: *Cannot find KDC for realm "ADDOMAIN.COM " * Following are me logs message after enabling the debug_level *sssd_nss.log* Thu Aug 25 11:05:08 2016) [sssd[nss]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb (Thu Aug 25 11:05:08 2016) [sssd[nss]] [confdb_get_domain_internal] (0x0400): No enumeration for [ipa.preprod.local]! (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sbus_init_connection] (0x0400): Adding connection 0x7fa634ad29b0 (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.service with path /org/freedesktop/sssd/service (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sbus_conn_register_path] (0x0400): Registering object path /org/freedesktop/sssd/service with D-Bus connection (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Properties with path /org/freedesktop/sssd/service (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Introspectable with path /org/freedesktop/sssd/service (Thu Aug 25 11:05:08 2016) [sssd[nss]] [monitor_common_send_id] (0x0100): Sending ID: (nss,1) (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_names_init_from_args] (0x0100): Using re [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))]. (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s]. (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sbus_init_connection] (0x0400): Adding connection 0x7fa634ad1710 (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.dataprovider_rev with path /org/freedesktop/sssd/dataprovider (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sbus_conn_register_path] (0x0400): Registering object path /org/freedesktop/sssd/dataprovider with D-Bus connection (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Properties with path /org/freedesktop/sssd/dataprovider (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Introspectable with path /org/freedesktop/sssd/dataprovider (Thu Aug 25 11:05:08 2016) [sssd[nss]] [dp_common_send_id] (0x0100): Sending ID to DP: (1,NSS) (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sysdb_domain_init_internal] (0x0200): DB File for ipa.preprod.local: /var/lib/sss/db/cache_ipa.preprod.local.ldb (Thu Aug 25 11:05:08 2016) [sssd[nss]] [ldb] (0x0400): asq: Unable to register control with rootdse! (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_process_init] (0x0400): Responder Initialization complete (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/ipa.preprod.local/root] to negative cache permanently (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/GROUP/ipa.preprod.local/root] to negative cache permanently (Thu Aug 25 11:05:08 2016) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /bin/sh in /etc/shells (Thu Aug 25 11:05:08 2016) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /bin/bash in /etc/shells (Thu Aug 25 11:05:08 2016) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /sbin/nologin in /etc/shells (Thu Aug 25 11:05:08 2016) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /usr/bin/sh in /etc/shells (Thu Aug 25 11:05:08 2016) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /usr/bin/bash in /etc/shells (Thu Aug 25 11:05:08 2016) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /usr/sbin/nologin in /etc/shells (Thu Aug 25 11:05:08 2016) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /bin/ksh in /etc/shells (Thu Aug 25 11:05:08 2016) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /bin/tcsh in /etc/shells (Thu Aug 25 11:05:08 2016) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /bin/csh in /etc/shells (Thu Aug 25 11:05:08 2016) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /bin/rksh in /etc/shells (Thu Aug 25 11:05:08 2016) [sssd[nss]] [responder_set_fd_limit] (0x0100): Maximum file descriptors set to [8192] (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_names_init_from_args] (0x0100): Using re [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))]. (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s]. (Thu Aug 25 11:05:08 2016) [sssd[nss]] [nss_process_init] (0x0400): NSS Initialization complete (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7fa63456a990:domains at ipa.preprod.local] (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_dp_get_domains_msg] (0x0400): Sending get domains request for [ipa.preprod.local][] (Thu Aug 25 11:05:08 2016) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7fa63456a990:domains at ipa.preprod.local] (Thu Aug 25 11:05:08 2016) [sssd[nss]] [dp_id_callback] (0x0100): Got id ack and version (1) from DP (Thu Aug 25 11:05:08 2016) [sssd[nss]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Thu Aug 25 11:05:09 2016) [sssd[nss]] [new_subdomain] (0x0400): Creating [ corp.addomain.com] as subdomain of [ipa.preprod.local]! (Thu Aug 25 11:05:09 2016) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Thu Aug 25 11:05:09 2016) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/ipa.preprod.local/root] to negative cache permanently (Thu Aug 25 11:05:09 2016) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Thu Aug 25 11:05:09 2016) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/GROUP/ipa.preprod.local/root] to negative cache permanently (Thu Aug 25 11:05:09 2016) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7fa63456a990:domains at ipa.preprod.local] (Thu Aug 25 11:05:10 2016) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected! (Thu Aug 25 11:05:10 2016) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Thu Aug 25 11:05:10 2016) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Thu Aug 25 11:05:10 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [aduser at corp.addomain.com]. (Thu Aug 25 11:05:10 2016) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'aduser at corp.addomain.com' matched expression for domain ' corp.addomain.com', user is aduser (Thu Aug 25 11:05:10 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [aduser] from [corp.addomain.com] (Thu Aug 25 11:05:10 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [aduser at corp.addomain.com] (Thu Aug 25 11:05:10 2016) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a LOCAL view, continuing with provided values. (Thu Aug 25 11:05:10 2016) [sssd[nss]] [check_cache] (0x0400): Cached entry is valid, returning.. (Thu Aug 25 11:05:10 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0400): Returning info for user [aduser at corp.addomain.com] (Thu Aug 25 11:05:14 2016) [sssd[nss]] [client_recv] (0x0200): Client disconnected! *krb5_child.log* (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13058]]]] [main] (0x0400): Will perform pre-auth (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13058]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [ADDOMAIN.COM] (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13058]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328230} during pre-auth. (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13058]]]] [k5c_send_data] (0x0200): Received error code 0 (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13058]]]] [main] (0x0400): krb5_child completed successfully (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [main] (0x0400): krb5_child started. (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [unpack_buffer] (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] enterprise principal [false] offline [false] UPN [Rajat.Gupta at ADDOMAIN.COM] (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [switch_creds] (0x0200): Switch user to [1007656917][1007656917]. (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ilt-gif-ipa02.ipa.preprod.local at IPA.PREPROD.LOCAL] (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [become_user] (0x0200): Trying to become user [1007656917][1007656917]. (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [main] (0x0400): Will perform online auth (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [ADDOMAIN.COM] (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [get_and_save_tgt] (0x0020): 1234: [-1765328230][Cannot find KDC for realm "ADDOMAIN.COM"] (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [map_krb5_error] (0x0020): 1303: [-1765328230][Cannot find KDC for realm "ADDOMAIN.COM"] (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Thu Aug 25 09:53:52 2016) [[sssd[krb5_child[13059]]]] [main] (0x0400): krb5_child completed successfully *sssd_pam.log* (Thu Aug 25 11:05:08 2016) [sssd[pam]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb (Thu Aug 25 11:05:08 2016) [sssd[pam]] [confdb_get_domain_internal] (0x0400): No enumeration for [ipa.preprod.local]! (Thu Aug 25 11:05:08 2016) [sssd[pam]] [confdb_get_domain_internal] (0x1000): pwd_expiration_warning is -1 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_init_connection] (0x0400): Adding connection 0x7f445ba66500 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_add_watch] (0x2000): 0x7f445ba6c130/0x7f445ba6ae70 (15), -/W (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6c130/0x7f445ba6aec0 (15), R/- (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.service with path /org/freedesktop/sssd/service (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_conn_register_path] (0x0400): Registering object path /org/freedesktop/sssd/service with D-Bus connection (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Properties with path /org/freedesktop/sssd/service (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Introspectable with path /org/freedesktop/sssd/service (Thu Aug 25 11:05:08 2016) [sssd[pam]] [monitor_common_send_id] (0x0100): Sending ID: (pam,1) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f445ba667f0 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6c130/0x7f445ba6aec0 (15), R/- (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6c130/0x7f445ba6ae70 (15), -/W (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sss_names_init_from_args] (0x0100): Using re [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))]. (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s]. (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_init_connection] (0x0400): Adding connection 0x7f445ba69d30 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_add_watch] (0x2000): 0x7f445ba6ce50/0x7f445ba69bc0 (16), -/W (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6ce50/0x7f445ba69c10 (16), R/- (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.dataprovider with path /org/freedesktop/sssd/dataprovider (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_conn_register_path] (0x0400): Registering object path /org/freedesktop/sssd/dataprovider with D-Bus connection (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Properties with path /org/freedesktop/sssd/dataprovider (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Introspectable with path /org/freedesktop/sssd/dataprovider (Thu Aug 25 11:05:08 2016) [sssd[pam]] [dp_common_send_id] (0x0100): Sending ID to DP: (1,PAM) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f445ba6dae0 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6ce50/0x7f445ba69c10 (16), R/- (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6ce50/0x7f445ba69bc0 (16), -/W (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sysdb_domain_init_internal] (0x0200): DB File for ipa.preprod.local: /var/lib/sss/db/cache_ipa.preprod.local.ldb (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f445ba71ae0 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f445ba71c10 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7f445ba71ae0 "ltdb_callback" (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7f445ba71c10 "ltdb_timeout" (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7f445ba71ae0 "ltdb_callback" (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x0400): asq: Unable to register control with rootdse! (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f445ba716f0 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f445ba72100 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7f445ba716f0 "ltdb_callback" (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7f445ba72100 "ltdb_timeout" (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7f445ba716f0 "ltdb_callback" (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f445ba724c0 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f445ba725f0 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7f445ba724c0 "ltdb_callback" (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7f445ba725f0 "ltdb_timeout" (Thu Aug 25 11:05:08 2016) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7f445ba724c0 "ltdb_callback" (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sss_process_init] (0x0400): Responder Initialization complete (Thu Aug 25 11:05:08 2016) [sssd[pam]] [get_trusted_uids] (0x0400): All UIDs are allowed. (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/ipa.preprod.local/root] to negative cache permanently (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sss_ncache_set_str] (0x0400): Adding [NCE/GROUP/ipa.preprod.local/root] to negative cache permanently (Thu Aug 25 11:05:08 2016) [sssd[pam]] [responder_set_fd_limit] (0x0100): Maximum file descriptors set to [8192] (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f445ab5c950:domains at ipa.preprod.local] (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sss_dp_get_domains_msg] (0x0400): Sending get domains request for [ipa.preprod.local][] (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f445ba6f0b0 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f445ab5c950:domains at ipa.preprod.local] (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba69d30 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba69d30 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba69d30 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6c130/0x7f445ba6aec0 (15), R/- (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6c130/0x7f445ba6ae70 (15), -/W (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6ce50/0x7f445ba69c10 (16), R/- (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6ce50/0x7f445ba69bc0 (16), -/W (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6c130/0x7f445ba6aec0 (15), R/- (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6c130/0x7f445ba6ae70 (15), -/W (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6ce50/0x7f445ba69c10 (16), R/- (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6ce50/0x7f445ba69bc0 (16), -/W (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6c130/0x7f445ba6aec0 (15), R/- (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6c130/0x7f445ba6ae70 (15), -/W (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6ce50/0x7f445ba69c10 (16), R/- (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6ce50/0x7f445ba69bc0 (16), -/W (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6c130/0x7f445ba6aec0 (15), R/- (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6c130/0x7f445ba6ae70 (15), -/W (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6ce50/0x7f445ba69c10 (16), R/- (enabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_toggle_watch] (0x4000): 0x7f445ba6ce50/0x7f445ba69bc0 (16), -/W (disabled) (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f445ba667f0 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:05:08 2016) [sssd[pam]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f445ba6dae0 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba69d30 (Thu Aug 25 11:05:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:05:08 2016) [sssd[pam]] [dp_id_callback] (0x0100): Got id ack and version (1) from DP (Thu Aug 25 11:05:09 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f445ba6f0b0 (Thu Aug 25 11:05:09 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba69d30 (Thu Aug 25 11:05:09 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:05:09 2016) [sssd[pam]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success (Success) (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f445ba71ae0 (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f445ba73860 (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7f445ba71ae0 "ltdb_callback" (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7f445ba73860 "ltdb_timeout" (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7f445ba71ae0 "ltdb_callback" (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f445ba7aa00 (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f445ba7ab30 (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7f445ba7aa00 "ltdb_callback" (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7f445ba7ab30 "ltdb_timeout" (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7f445ba7aa00 "ltdb_callback" (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f445ba7aa00 (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f445ba6c290 (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7f445ba7aa00 "ltdb_callback" (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7f445ba6c290 "ltdb_timeout" (Thu Aug 25 11:05:09 2016) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7f445ba7aa00 "ltdb_callback" (Thu Aug 25 11:05:09 2016) [sssd[pam]] [new_subdomain] (0x0400): Creating [ corp.addomain.com] as subdomain of [ipa.preprod.local]! (Thu Aug 25 11:05:09 2016) [sssd[pam]] [link_forest_roots] (0x2000): [ipa.preprod.local] is a forest root (Thu Aug 25 11:05:09 2016) [sssd[pam]] [link_forest_roots] (0x2000): [ corp.addomain.com] is a forest root (Thu Aug 25 11:05:09 2016) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Thu Aug 25 11:05:09 2016) [sssd[pam]] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/ipa.preprod.local/root] to negative cache permanently (Thu Aug 25 11:05:09 2016) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Thu Aug 25 11:05:09 2016) [sssd[pam]] [sss_ncache_set_str] (0x0400): Adding [NCE/GROUP/ipa.preprod.local/root] to negative cache permanently (Thu Aug 25 11:05:09 2016) [sssd[pam]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f445ab5c950:domains at ipa.preprod.local] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [get_client_cred] (0x4000): Client creds: euid[0] egid[0] pid[20171]. (Thu Aug 25 11:05:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f445ba74990][19] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [accept_fd_handler] (0x0400): Client connected to privileged pipe! (Thu Aug 25 11:05:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f445ba74990][19] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. (Thu Aug 25 11:05:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f445ba74990][19] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f445ba74990][19] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_cmd_preauth] (0x0100): entering pam_cmd_preauth (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'aduser at corp.addomain.com' matched expression for domain ' corp.addomain.com', user is aduser (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_PREAUTH (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): user: aduser (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: ilt-gif-ipa02.ipa.preprod.local (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 20171 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: aduser at corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/corp.addomain.com/aduser] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_initgr_check_timeout] (0x4000): User [aduser at corp.addomain.com] not found in PAM cache. (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f445ab5b090:3:aduser at corp.addomain.com] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [corp.addomain.com][3][1][name=aduser] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f445ba667f0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f445ab5b090:3:aduser at corp.addomain.com] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f445ba667f0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba69d30 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success (Success) (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [aduser at corp.addomain.com] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f445ba6f610 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f445ba7aa00 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7f445ba6f610 "ltdb_callback" (Thu Aug 25 11:05:13 2016) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7f445ba7aa00 "ltdb_timeout" (Thu Aug 25 11:05:13 2016) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7f445ba6f610 "ltdb_callback" (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [aduser at corp.addomain.com] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is aduser at corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_initgr_cache_set] (0x2000): [ aduser at corp.addomain.com] added to PAM initgroup cache (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_PREAUTH (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): user: aduser at corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: ilt-gif-ipa02.ipa.preprod.local (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 20171 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: aduser at corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f445ba70720 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f445ab5b090:3:aduser at corp.addomain.com] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f445ba70720 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba69d30 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][corp.addomain.com] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 36 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f445ba74990][19] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f445ba74990][19] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'aduser at corp.addomain.com' matched expression for domain ' corp.addomain.com', user is aduser (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): user: aduser (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: ilt-gif-ipa02.ipa.preprod.local (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 20171 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: aduser at corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/corp.addomain.com/aduser] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_initgr_check_timeout] (0x2000): User [aduser at corp.addomain.com] found in PAM cache. (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [aduser at corp.addomain.com] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f445ba74cf0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f445ba76e80 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7f445ba74cf0 "ltdb_callback" (Thu Aug 25 11:05:13 2016) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7f445ba76e80 "ltdb_timeout" (Thu Aug 25 11:05:13 2016) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7f445ba74cf0 "ltdb_callback" (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [aduser at corp.addomain.com] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is aduser at corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): user: aduser at corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: ilt-gif-ipa02.ipa.preprod.local (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 20171 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: aduser at corp.addomain.com (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f445ba6e6c0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f445ba6e6c0 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba69d30 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][corp.addomain.com] (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. (Thu Aug 25 11:05:13 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 36 (Thu Aug 25 11:05:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f445ba74990][19] (Thu Aug 25 11:05:14 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f445ba74990][19] (Thu Aug 25 11:05:14 2016) [sssd[pam]] [client_recv] (0x0200): Client disconnected! (Thu Aug 25 11:05:14 2016) [sssd[pam]] [client_destructor] (0x2000): Terminated client [0x7f445ba74990][19] (Thu Aug 25 11:05:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:05:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:05:18 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:05:18 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:05:18 2016) [sssd[pam]] [pam_initgr_cache_remove] (0x2000): [ aduser at corp.addomain.com] removed from PAM initgroup cache (Thu Aug 25 11:05:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:05:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:05:28 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:05:28 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:05:38 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:05:38 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:05:38 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:05:38 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:05:48 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:05:48 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:05:48 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:05:48 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:05:58 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:05:58 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:05:58 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:05:58 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:06:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:06:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:06:08 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:06:08 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:06:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:06:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:06:18 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:06:18 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:06:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:06:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:06:28 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:06:28 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:06:38 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:06:38 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:06:38 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:06:38 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:06:48 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:06:48 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:06:48 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:06:48 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:06:58 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:06:58 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:06:58 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:06:58 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:07:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:07:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:07:08 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:07:08 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:07:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:07:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:07:18 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:07:18 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:07:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:07:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:07:28 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:07:28 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:07:38 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:07:38 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:07:38 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:07:38 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:07:48 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:07:48 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:07:48 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:07:48 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:07:58 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:07:58 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:07:58 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:07:58 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:08:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:08:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:08:08 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:08:08 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:08:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:08:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:08:18 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:08:18 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:08:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:08:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:08:28 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:08:28 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:08:38 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:08:38 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:08:38 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:08:38 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:08:48 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:08:48 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:08:48 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:08:48 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:08:58 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:08:58 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:08:58 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:08:58 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:09:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:09:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:09:08 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:09:08 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:09:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:09:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:09:18 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:09:18 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:09:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:09:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:09:28 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:09:28 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:09:38 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:09:38 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:09:38 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:09:38 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:09:48 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:09:48 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:09:48 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:09:48 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:09:58 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:09:58 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:09:58 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:09:58 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:10:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:10:08 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:10:08 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:10:08 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:10:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:10:18 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:10:18 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:10:18 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Aug 25 11:10:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f445ba66500 (Thu Aug 25 11:10:28 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Aug 25 11:10:28 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Aug 25 11:10:28 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit /Rajat On Thu, Aug 18, 2016 at 9:48 AM, rajat gupta wrote: > Thanks. > > When i am trying to accesses user with password i am getting below message > in logs. > > *Aug 18 09:38:17 ilt-gif-ipa02 [sssd[krb5_child[8505]]]: Cannot find KDC > for realm "ADDOMAON.COM "* > > when i connect through ssh, it tries to contact the KDC for the realm *ADDOMAON.COM > * > > which should be corp.addomain.com > > > Do you have any further comments or suggestions that may help us. > > > /Rajat > > > > On Tue, Aug 16, 2016 at 2:46 PM, Alexander Bokovoy > wrote: > >> On Tue, 16 Aug 2016, rajat gupta wrote: >> >>> Hi, >>> >>> >>> I have done IPA AD trust between IPA and AD server. But trust is showing >>> offline always. But we are able to get the AD user information. And able >>> to >>> grant the KRB ticket. >>> >>> >>> >>> # wbinfo --online-status >>> BUILTIN : online >>> IPA : online >>> *CORP : offline* >>> >> Don't use wbinfo. Its output is irrelevant starting from FreeIPA 3.3. >> >> >>> >>> #id aduser at CORP.ADDOMAIN.COM >>> uid=1007656917(aduser at corp.addomain.com) gid=1007656917( >>> aduser at corp.addomain.com) groups=1007656917(aduser at corp.addomain.com >>> ),1007715891(prg-msoffice2013pro(kms)@corp.addomain.com),1007663829( >>> da-eeg-intra-read at corp.addomain.com),1007600513(domain >>> users at corp.addomain.com) >>> >>> >>> [root at ilt-gif-ipa01 ~]# kinit aduser at CORP.ADDOMAIN.COM >>> Password for aduser at CORP.ADDOMAIN.COM: >>> [root at ilt-gif-ipa01 ~]# >>> [root at ilt-gif-ipa01 ~]# >>> [root at ilt-gif-ipa01 ~]# klist >>> Ticket cache: KEYRING:persistent:0:0 >>> Default principal: aduser at CORP.ADDOMAIN.COM >>> >>> Valid starting Expires Service principal >>> 08/11/2016 13:11:35 08/11/2016 23:11:35 krbtgt/ >>> CORP.ADDOMAIN.COM at CORP.ADDOMAIN.COM >>> renew until 08/12/2016 13:11:29 >>> [root at ilt-gif-ipa01 ~]# >>> >> This is irrelevant for the trust case because you are authenticating >> against AD DCs, not IPA KDCs. >> >> >>> >>> >>> Form IPA client server we are able to get the all thinks ( KRB ticket/ >>> user/groups ) >>> >>> [root at ilt-gif-ipa02 ~]# getent passwd aduser at CORP.addomain.COM >>> aduser at corp.addomain.com:*:1007656917:1007656917:USER NAME:/home/ >>> corp.addomain.com/aduser: >>> [root at ilt-gif-ipa02 ~]# >>> >>> >>> [root at ilt-gif-ipa02 ~]# getent group aduser at CORP.addomain.COM >>> aduser at corp.addomain.com:*:1007656917: >>> [root at ilt-gif-ipa02 ~]# >>> >>> >>> [root at ilt-gif-ipa02 ~]# id aduser at CORP.addomain.COM >>> uid=1007656917(aduser at corp.addomain.com) gid=1007656917( >>> aduser at corp.addomain.com) groups=1007656917(aduser at corp.addomain.com >>> ),1007715891(prg-msoffice2013pro(kms)@corp.addomain.com),1007663829( >>> da-eeg-intra-read at corp.addomain.com),1007600513(domain >>> users at corp.addomain.com),1007725088(tfs_users at corp.addomain.com) >>> >>> >>> Also we are to ssh to IPA client on same machine or from some other >>> machine with gss authentication. But using password authentication it?s >>> failed to login. >>> >>> *ERROR:- pam_sss(sshd:auth): authentication failure; logname* >>> >>> >>> >>> kinit aduser at CORP.ADDOMAIN.COM >>> Password for aduser at CORP.ADDOMAIN.COM: >>> >>> >>> >>> [root at ilt-gif-ipa02 ~]# ssh -vl aduser at corp.addomain.com >>> ilt-gif-ipa02.ipa.preprod.local >>> OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013 >>> debug1: Reading configuration data /etc/ssh/ssh_config >>> debug1: /etc/ssh/ssh_config line 60: Applying options for * >>> debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy >>> -p >>> 22 ilt-gif-ipa02.ipa.preprod.local >>> debug1: permanently_set_uid: 0/0 >>> debug1: permanently_drop_suid: 0 >>> debug1: identity file /root/.ssh/id_rsa type -1 >>> debug1: identity file /root/.ssh/id_rsa-cert type -1 >>> debug1: identity file /root/.ssh/id_dsa type -1 >>> debug1: identity file /root/.ssh/id_dsa-cert type -1 >>> debug1: identity file /root/.ssh/id_ecdsa type -1 >>> debug1: identity file /root/.ssh/id_ecdsa-cert type -1 >>> debug1: identity file /root/.ssh/id_ed25519 type -1 >>> debug1: identity file /root/.ssh/id_ed25519-cert type -1 >>> debug1: Enabling compatibility mode for protocol 2.0 >>> debug1: Local version string SSH-2.0-OpenSSH_6.6.1 >>> debug1: Remote protocol version 2.0, remote software version >>> OpenSSH_6.6.1 >>> debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 >>> debug1: SSH2_MSG_KEXINIT sent >>> debug1: SSH2_MSG_KEXINIT received >>> debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none >>> debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none >>> debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 >>> debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 >>> debug1: sending SSH2_MSG_KEX_ECDH_INIT >>> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY >>> debug1: Server host key: ECDSA >>> f0:e6:b2:66:c8:41:06:4e:83:a4:a2:c5:5a:57:24:66 >>> debug1: Host 'ilt-gif-ipa02.ipa.preprod.local' is known and matches the >>> ECDSA host key. >>> debug1: Found key in /root/.ssh/known_hosts:3 >>> debug1: ssh_ecdsa_verify: signature correct >>> debug1: SSH2_MSG_NEWKEYS sent >>> debug1: expecting SSH2_MSG_NEWKEYS >>> debug1: SSH2_MSG_NEWKEYS received >>> debug1: SSH2_MSG_SERVICE_REQUEST sent >>> debug1: SSH2_MSG_SERVICE_ACCEPT received >>> debug1: Authentications that can continue: >>> publickey,gssapi-keyex,gssapi-with-mic,password >>> debug1: Next authentication method: gssapi-keyex >>> debug1: No valid Key exchange context >>> debug1: Next authentication method: gssapi-with-mic >>> *debug1: Authentication succeeded (gssapi-with-mic).* >>> Authenticated to ilt-gif-ipa02.ipa.preprod.local (via proxy). >>> debug1: channel 0: new [client-session] >>> debug1: Requesting no-more-sessions at openssh.com >>> debug1: Entering interactive session. >>> debug1: Sending environment. >>> debug1: Sending env LANG = en_US.UTF-8 >>> Last login: Thu Aug 11 13:17:05 2016 from ilt-gif-ipa02.ipa.preprod.loca >>> l >>> >>> RHN kickstart on 2014-10-16 >>> >>> -sh-4.2$ pwd >>> /home/corp.addomain.com/aduser >>> -sh-4.2$ who am i >>> aduser at corp.addomain.com pts/3 2016-08-11 13:19 >>> (ilt-gif-ipa02.ipa.preprod.local) >>> -sh-4.2$ >>> >>> >>> >>> ]# ssh aduser at corp.addomain.com@ilt-gif-ipa02.ipa.preprod.local >>> e600336 at corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password: >>> Permission denied, please try again. >>> e600336 at corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password: >>> >>> >>> Can you please help me i am not able to login with AD user >>> password authentication. >>> >> If you cannot login with password but can with Kerberos credentials, you >> need to look into SSSD logs on the ilt-gif-ipa02.ipa.preprod.local host. >> See https://fedorahosted.org/sssd/wiki/Troubleshooting >> >> >> -- >> / Alexander Bokovoy >> > > > > -- > > *Rajat Gupta * > -- *Rajat Gupta * -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Aug 25 09:27:20 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 25 Aug 2016 12:27:20 +0300 Subject: [Freeipa-devel] [PATCH] 0220 move /bin/ipa to freeipa-client Message-ID: <20160825092720.242twohhey7pf2vs@redhat.com> Hi, attached patch moves ipa CLI to freeipa-client and obsoletes freeipa-admintools Solves https://fedorahosted.org/freeipa/ticket/5934 Here is how upgrade looks when running 'dnf': Upgrading: freeipa-client x86_64 4.4.0.201608250913GIT9c20682-0.fc24 @commandline 146 k replacing freeipa-admintools.noarch 4.4.0.201608051228GIT590e30f-0.fc24 -- / Alexander Bokovoy -------------- next part -------------- From 8a22131718cf6fdbff380ff447b502d22c735f1a Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 25 Aug 2016 11:59:34 +0300 Subject: [PATCH] freeipa.spec.in: move ipa CLI utility to freeipa-client There is no notable package size cost, as all the libraries and packages are already in the freeipa-client package and freeipa-admintools only contained a short shim calling this code. Move /bin/ipa to freeipa-client, along with a man page and bash completion. Resolves: https://fedorahosted.org/freeipa/ticket/5934 --- freeipa.spec.in | 41 ++++++++++------------------------------- 1 file changed, 10 insertions(+), 31 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index e3ad5b6..a9308dd 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -1,4 +1,4 @@ -# Define ONLY_CLIENT to only make the ipa-admintools, ipa-client and ipa-python +# Define ONLY_CLIENT to only make the ipa-client and ipa-python # subpackages %{!?ONLY_CLIENT:%global ONLY_CLIENT 0} @@ -135,7 +135,6 @@ Summary: The IPA authentication server Group: System Environment/Base Requires: %{name}-server-common = %{version}-%{release} Requires: %{name}-client = %{version}-%{release} -Requires: %{name}-admintools = %{version}-%{release} Requires: %{name}-common = %{version}-%{release} Requires: python2-ipaserver = %{version}-%{release} Requires: 389-ds-base >= 1.3.5.6 @@ -349,6 +348,11 @@ Requires(post): policycoreutils Provides: %{alt_name}-client = %{version} Conflicts: %{alt_name}-client Obsoletes: %{alt_name}-client < %{version} +Provides: %{name}-admintools = %{version}-%{release} +Obsoletes: %{name}-admintools < %{version} +Provides: %{alt_name}-admintools = %{version} +Conflicts: %{alt_name}-admintools +Obsoletes: %{alt_name}-admintools < %{version} %description client IPA is an integrated solution to provide centrally managed Identity (users, @@ -358,6 +362,7 @@ features for further integration with Linux based clients (SUDO, automount) and integration with Active Directory based infrastructures (Trusts). If your network uses IPA for authentication, this package should be installed on every client machine. +This package provides command-line tools for IPA administrators. %package -n python2-ipaclient @@ -423,26 +428,6 @@ If your network uses IPA for authentication, this package should be installed on every client machine. -%package admintools -Summary: IPA administrative tools -Group: System Environment/Base -BuildArch: noarch -Requires: python2-ipaclient = %{version}-%{release} -Requires: python-ldap - -Provides: %{alt_name}-admintools = %{version} -Conflicts: %{alt_name}-admintools -Obsoletes: %{alt_name}-admintools < %{version} - -%description admintools -IPA is an integrated solution to provide centrally managed Identity (users, -hosts, services), Authentication (SSO, 2FA), and Authorization -(host access control, SELinux user roles, services). The solution provides -features for further integration with Linux based clients (SUDO, automount) -and integration with Active Directory based infrastructures (Trusts). -This package provides command-line tools for IPA administrators. - - %package python-compat Summary: Compatiblity package for Python libraries used by IPA Group: System Environment/Libraries @@ -1293,6 +1278,9 @@ fi %{_sbindir}/ipa-getkeytab %{_sbindir}/ipa-rmkeytab %{_sbindir}/ipa-join +%{_bindir}/ipa +%config %{_sysconfdir}/bash_completion.d +%{_mandir}/man1/ipa.1.gz %{_mandir}/man1/ipa-getkeytab.1.gz %{_mandir}/man1/ipa-rmkeytab.1.gz %{_mandir}/man1/ipa-client-install.1.gz @@ -1352,15 +1340,6 @@ fi %{_mandir}/man5/default.conf.5.gz -%files admintools -%defattr(-,root,root,-) -%doc README Contributors.txt -%license COPYING -%{_bindir}/ipa -%config %{_sysconfdir}/bash_completion.d -%{_mandir}/man1/ipa.1.gz - - %files python-compat %defattr(-,root,root,-) %doc README Contributors.txt -- 2.7.4 From jcholast at redhat.com Thu Aug 25 10:08:55 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Aug 2016 12:08:55 +0200 Subject: [Freeipa-devel] [PATCH] 0091 Allow full customisability of CA subject name In-Reply-To: <20160822050057.GV3877@dhcp-40-8.bne.redhat.com> References: <20160715050448.GE10771@dhcp-40-8.bne.redhat.com> <20160715050539.GF10771@dhcp-40-8.bne.redhat.com> <83eb61a6-4e1f-d33a-1bbb-dacf8de522af@redhat.com> <20160719095445.GU10771@dhcp-40-8.bne.redhat.com> <4f7384ee-e648-2adb-3c86-26e297ede481@redhat.com> <63eec8fe-b64d-00db-f516-ccff6e8220a5@redhat.com> <20160815125425.GM23927@dhcp-40-8.bne.redhat.com> <20160819100933.GM3877@dhcp-40-8.bne.redhat.com> <20160822050057.GV3877@dhcp-40-8.bne.redhat.com> Message-ID: <6c5080d5-f0fa-655d-71de-e2a8f474ffa6@redhat.com> On 22.8.2016 07:00, Fraser Tweedale wrote: > On Fri, Aug 19, 2016 at 08:09:33PM +1000, Fraser Tweedale wrote: >> On Mon, Aug 15, 2016 at 10:54:25PM +1000, Fraser Tweedale wrote: >>> On Mon, Aug 15, 2016 at 02:08:54PM +0200, Jan Cholasta wrote: >>>> On 19.7.2016 12:05, Jan Cholasta wrote: >>>>> On 19.7.2016 11:54, Fraser Tweedale wrote: >>>>>> On Tue, Jul 19, 2016 at 09:36:17AM +0200, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 15.7.2016 07:05, Fraser Tweedale wrote: >>>>>>>> On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: >>>>>>>>> The attached patch is a work in progress for >>>>>>>>> https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). >>>>>>>>> >>>>>>>>> I am sharing now to make the approach clear and solicit feedback. >>>>>>>>> >>>>>>>>> It has been tested for server install, replica install (with and >>>>>>>>> without CA) and CA-replica install (all hosts running master+patch). >>>>>>>>> >>>>>>>>> Migration from earlier versions and server/replica/CA install on a >>>>>>>>> CA-less deployment are not yet tested; these will be tested over >>>>>>>>> coming days and patch will be tweaked as necessary. >>>>>>>>> >>>>>>>>> Commit message has a fair bit to say so I won't repeat here but let >>>>>>>>> me know your questions and comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Fraser >>>>>>>>> >>>>>>>> It does help to attach the patch, of course ^_^ >>>>>>> >>>>>>> IMO explicit is better than implicit, so instead of introducing >>>>>>> additional >>>>>>> magic around --subject, I would rather add a new separate option for >>>>>>> specifying the CA subject name (I think --ca-subject, for consistency >>>>>>> with >>>>>>> --ca-signing-algorithm). >>>>>>> >>>>>> The current situation - the --subject argument which specifies the >>>>>> not the subject but the subject base, is confusing enough (to say >>>>>> nothing of the limitations that give rise to the RFE). >>>>>> >>>>>> Retaining --subject for specifying the subject base and adding >>>>>> --ca-subject for specifying the *actual* subject DN gets us over the >>>>>> line in terms of the RFE, but does not make the installer less >>>>>> confusing. This is why I made --subject accept the full subject DN, >>>>>> with provisions to retain existing behaviour. >>>>>> >>>>>> IMO if we want to have separate arguments for subject DN and subject >>>>>> base (I am not against it), let's bite the bullet and name arguments >>>>>> accordingly. --subject should be used to specify full Subject DN, >>>>>> --subject-base (or similar) for specifying subject base. >>>>> >>>>> IMHO --ca-subject is better than --subject, because it is more explicit >>>>> whose subject name that is (the CA's). I agree that --subject should be >>>>> deprecated and replaced with --subject-base. >>>>> >>>>>> >>>>>> (I intentionally defer discussion of specific behaviour if one, none >>>>>> or both are specified; let's resolve the question or renaming / >>>>>> changing meaning of arguments first). >>>>>> >>>>>> >>>>>>> By specifying the option you would override the default "CN=Certificate >>>>>>> Authority,$SUBJECT_BASE" subject name. If --external-ca was not used, >>>>>>> additional validation would be done to make sure the subject name meets >>>>>>> Dogtag's expectations. Actually, it might make sense to always do the >>>>>>> additional validation, to be able to print a warning that if a >>>>>>> Dogtag-incompatible subject name is used, it won't be possible to >>>>>>> change the >>>>>>> CA cert chaining from externally signed to self-signed later. >>>>>>> >>>>>>> Honza >>>> >>>> Bump, any update on this? >>>> >>> I have an updated patch that fixes some issues Sebastian encountered >>> in testing, but I've not yet tackled the main change requested by >>> Honza (in brief: adding --ca-subject for specifying that, adding >>> --subject-base for specifying that, and deprecating --subject; >>> Sebastian, see discussion above and feel free to give your >>> thoughts). I expect I'll get back onto this work within the next >>> few days. >>> >> Update: I've got an updated version of patch almost ready for >> review, but I'm still ironing out some wrinkles in replica >> installation. >> >> Expect to be able to send it Monday or Tuesday for review. >> > Updated patch attached. > > I expect it will take a while to review, test and get the ACK, but > in any case: IMO it should not be merged until after ipa-4-4 branch > gets created. 1) Please fix these: $ git show -U0 | pep8 --diff ./ipaserver/install/cainstance.py:508:13: E128 continuation line under-indented for visual indent ./ipaserver/install/dsinstance.py:259:5: E303 too many blank lines (2) ./ipaserver/install/installutils.py:999:1: E302 expected 2 blank lines, found 1 ./ipaserver/install/server/common.py:161:80: E501 line too long (101 > 79 characters) ./ipaserver/install/server/replicainstall.py:93:80: E501 line too long (82 > 79 characters) ./ipaserver/install/server/replicainstall.py:604:80: E501 line too long (81 > 79 characters) 2) Please put 3rd party library (such as six) imports between standard library imports and ipa imports. 3) ipa-ca-install should also have the --subject-base and --ca-subject options. 4) Please use the original method of getting the configured subject base from ipacertificatesubjectbase of the config object rather than DSInstance.find_subject_base(), which is horrendous and should in fact be obliterated (not necessarily in this patch). 5) You can use "unicode(x509.get_subject(cert))" to get subject name of a cert instead of "unicode(x509.load_certificate(cert).subject)". 6) For every removed "options.subject = ..." there should be a "options.subject_base ..." added. 7) The subject base read from replica config should be respected, i.e. this bit in ipa-ca-install should stay: - if config.subject_base is None: - attrs = conn.get_ipa_config() - config.subject_base = attrs.get('ipacertificatesubjectbase')[0] Also I would move the rest of the "look up CA subject name" to between options.ca_cert_file assignment and ca.install_check() call: else: options.ca_cert_file = None + # look up CA subject name (needed for DS certmap.conf) + ipa_ca_nickname = get_ca_nickname(config.realm_name) + db = certs.CertDB(config.realm_name, nssdir=paths.IPA_NSSDB_DIR) + cert = db.get_cert_from_db(ipa_ca_nickname) + options.ca_subject = unicode(x509.load_certificate(cert).subject) + ca.install_check(True, config, options) if options.promote: ca_data = (os.path.join(config.dir, 'cacert.p12'), 8) I think we should remove --subject from ipa-server-install man page altogether. 9) I don't like that the default values are set in multiple places (CAInstance.configure_instance(), CAInstance.configure_replica(), KRAInstance.configure_instance(), KRAInstance.configure_replica(), ipa-server-install). The defaults should be handled in one place - ca.py - and the values (read from configuration or specified by user or default) should be passed through arguments to CAInstance/KRAInstance. 10) Nitpick, but the ca_subject_dn argument of CertDB() would be better called just ca_subject and be located after subject_base, for consistency with the rest of the patch. Maybe also rename the subject argument of the various CAInstance and KRAInstance methods to ca_subject? 11) I see that there was some code which ignored the configured subject base. I think the fixes for that should be moved into a separate patch and maybe even a separate ticket. 12) The proper way to rename a Knob and keep the old name is to put the old name in cli_aliases of the renamed Knob rather than add a new Knob, like this: subject_base = Knob( str, None, description="The certificate subject base (default O=)", cli_aliases=['subject'], ) This way you wouldn't be able to issue a warning when --subject is used, but that's OK, as we don't do it for any other renamed options too. 13) AFAIK CN is in fact not valid in a subject base, so it should not be added to VALID_SUBJECT_ATTRS. 14) NACK on the normalization stuff. It's not really normalization if the original value is not equal to the normalized value. Instead of this you should validate if the provided subject name is suitable for Dogtag and if it isn't, fail and inform the user what the acceptable format is. 15) Subject base setting is not respected for most of our certs. This is with --subject-base='O=Test': $ sudo getcert list | grep subject subject: CN=CA Audit,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=OCSP Subsystem,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=CA Subsystem,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=Certificate Authority,O=Test subject: CN=IPA RA,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=vm-058-193.abc.idm.lab.eng.brq.redhat.com,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=vm-058-193.abc.idm.lab.eng.brq.redhat.com,O=Test subject: CN=vm-058-193.abc.idm.lab.eng.brq.redhat.com,O=Test This is most likely because of 5) and 8) combined. 16) Spaces do not work. This is with --subject-base='O=My Organization': $ ipa config-show | grep 'Subject base' Certificate Subject base: O=My $ sudo getcert list | grep 'subject' subject: CN=CA Audit,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=OCSP Subsystem,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=CA Subsystem,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=Certificate Authority,O=My subject: CN=IPA RA,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=vm-058-193.abc.idm.lab.eng.brq.redhat.com,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=vm-058-193.abc.idm.lab.eng.brq.redhat.com,O=My subject: CN=vm-058-193.abc.idm.lab.eng.brq.redhat.com,O=My I blame the normalization. See also 13). 17) CN in subject base does not work. This is with --subject-base='CN=Test': $ sudo getcert list | grep subject subject: CN=CA Audit,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=OCSP Subsystem,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=CA Subsystem,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=Certificate Authority,CN=Test subject: CN=IPA RA,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=vm-058-193.abc.idm.lab.eng.brq.redhat.com,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM subject: CN=Test,CN=Test subject: CN=Test,CN=Test See 12). 18) In CA-less topology, ipa-replica-install fails: 2016-08-25T09:54:09Z DEBUG Starting external process 2016-08-25T09:54:09Z DEBUG args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n ABC.IDM.LAB.ENG.BRQ.REDHAT.COM IPA CA -a 2016-08-25T09:54:09Z DEBUG Process finished, return code=255 2016-08-25T09:54:09Z DEBUG stdout= 2016-08-25T09:54:09Z DEBUG stderr=certutil: Could not find cert: ABC.IDM.LAB.ENG.BRQ.REDHAT.COM IPA CA : PR_FILE_NOT_FOUND_ERROR: File not found 2016-08-25T09:54:09Z DEBUG Destroyed connection context.ldap2_140045224192976 2016-08-25T09:54:09Z DEBUG Starting external process 2016-08-25T09:54:09Z DEBUG args=/usr/sbin/ipa-client-install --unattended --uninstall 2016-08-25T09:54:18Z DEBUG Process finished, return code=0 2016-08-25T09:54:18Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() ----8<------ File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1722, in main promote_check(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 364, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 386, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1266, in promote_check options.ca_subject = unicode(x509.load_certificate(cert).subject) File "/usr/lib/python2.7/site-packages/ipalib/x509.py", line 125, in load_certificate return nss.Certificate(buffer(data)) # pylint: disable=buffer-builtin 2016-08-25T09:54:18Z DEBUG The ipa-replica-install command failed, exception: NSPRError: (SEC_ERROR_LIBRARY_FAILURE) security library failure. 2016-08-25T09:54:18Z ERROR (SEC_ERROR_LIBRARY_FAILURE) security library failure. 2016-08-25T09:54:18Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information 19) In CA-less topology, ipa-ca-install fails: 2016-08-25T09:58:21Z DEBUG raw: ca_show(u'ipa', version=u'2.212') 2016-08-25T09:58:21Z DEBUG ca_show(u'ipa', rights=False, all=False, raw=False, version=u'2.212') 2016-08-25T09:58:21Z DEBUG raw: ca_is_enabled(version=u'2.212') 2016-08-25T09:58:21Z DEBUG ca_is_enabled(version=u'2.212') 2016-08-25T09:58:21Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 752, in run_script return_value = main_function() File "/sbin/ipa-ca-install", line 309, in main promote(safe_options, options, filename) File "/sbin/ipa-ca-install", line 279, in promote install_master(safe_options, options) File "/sbin/ipa-ca-install", line 232, in install_master subject = api.Command.ca_show(IPA_CA_CN)['result']['ipacasubjectdn'] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ return self.__do_call(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run return self.execute(*args, **options) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ca.py", line 144, in execute ca_enabled_check() File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 222, in ca_enabled_check raise errors.NotFound(reason=_('CA is not configured')) 2016-08-25T09:58:21Z DEBUG The ipa-ca-install command failed, exception: NotFound: CA is not configured This is related to 3). Honza -- Jan Cholasta From freeipa-github-notification at redhat.com Thu Aug 25 10:39:57 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Thu, 25 Aug 2016 12:39:57 +0200 Subject: [Freeipa-devel] [freeipa PR#19] WebUI: Add 'Restore' option to action dropdown menu (opened) In-Reply-To: References: Message-ID: pvomacka's pull request #19: "WebUI: Add 'Restore' option to action dropdown menu" was opened PR body: """ Also moving activate_action method several lines up - correcting logical order of methods. https://fedorahosted.org/freeipa/ticket/5818 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/19 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/19/head:pr19 git checkout pr19 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-19.patch URL: From jcholast at redhat.com Thu Aug 25 10:45:08 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Aug 2016 12:45:08 +0200 Subject: [Freeipa-devel] [PATCH] 0220 move /bin/ipa to freeipa-client In-Reply-To: <20160825092720.242twohhey7pf2vs@redhat.com> References: <20160825092720.242twohhey7pf2vs@redhat.com> Message-ID: <25322a89-9557-7790-7f81-af1aedcc8807@redhat.com> Hi, On 25.8.2016 11:27, Alexander Bokovoy wrote: > Hi, > > attached patch moves ipa CLI to freeipa-client and obsoletes > freeipa-admintools The Obsoletes (both) should be on version < 4.4.1 rather than %{version}, as per Fedora packaging guidelines [1]. Please move the Obsoletes and Provides on %{name}-admintools right below Group (Obsoletes first) and put a newline between the %{alt_name}-client and %{alt_name}-admintools blocks, for consistent layout accross all subpackages in the spec file. > > Solves https://fedorahosted.org/freeipa/ticket/5934 > > Here is how upgrade looks when running 'dnf': > > Upgrading: > freeipa-client x86_64 > 4.4.0.201608250913GIT9c20682-0.fc24 @commandline > 146 k > replacing freeipa-admintools.noarch > 4.4.0.201608051228GIT590e30f-0.fc24 I'm going to test with yum as well, for RHEL and CentOS. Honza [1] -- Jan Cholasta From abokovoy at redhat.com Thu Aug 25 11:09:30 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 25 Aug 2016 14:09:30 +0300 Subject: [Freeipa-devel] [PATCH] 0220 move /bin/ipa to freeipa-client In-Reply-To: <25322a89-9557-7790-7f81-af1aedcc8807@redhat.com> References: <20160825092720.242twohhey7pf2vs@redhat.com> <25322a89-9557-7790-7f81-af1aedcc8807@redhat.com> Message-ID: <20160825110930.vimskikhtn2lwmmy@redhat.com> On Thu, 25 Aug 2016, Jan Cholasta wrote: >Hi, > >On 25.8.2016 11:27, Alexander Bokovoy wrote: >>Hi, >> >>attached patch moves ipa CLI to freeipa-client and obsoletes >>freeipa-admintools > >The Obsoletes (both) should be on version < 4.4.1 rather than >%{version}, as per Fedora packaging guidelines [1]. > >Please move the Obsoletes and Provides on %{name}-admintools right >below Group (Obsoletes first) and put a newline between the >%{alt_name}-client and %{alt_name}-admintools blocks, for consistent >layout accross all subpackages in the spec file. > >> >>Solves https://fedorahosted.org/freeipa/ticket/5934 >> >>Here is how upgrade looks when running 'dnf': >> >>Upgrading: >>freeipa-client x86_64 >>4.4.0.201608250913GIT9c20682-0.fc24 @commandline >>146 k >> replacing freeipa-admintools.noarch >>4.4.0.201608051228GIT590e30f-0.fc24 > >I'm going to test with yum as well, for RHEL and CentOS. Updated patch attached. -- / Alexander Bokovoy -------------- next part -------------- From 2256c872ec31223c8d1c3dcfbf715326ccd0b2b2 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 25 Aug 2016 11:59:34 +0300 Subject: [PATCH 2/2] freeipa.spec.in: move ipa CLI utility to freeipa-client There is no notable package size cost, as all the libraries and packages are already in the freeipa-client package and freeipa-admintools only contained a short shim calling this code. Move /bin/ipa to freeipa-client, along with a man page and bash completion. Resolves: https://fedorahosted.org/freeipa/ticket/5934 --- freeipa.spec.in | 43 ++++++++++++------------------------------- 1 file changed, 12 insertions(+), 31 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index e3ad5b6..589060b 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -1,4 +1,4 @@ -# Define ONLY_CLIENT to only make the ipa-admintools, ipa-client and ipa-python +# Define ONLY_CLIENT to only make the ipa-client and ipa-python # subpackages %{!?ONLY_CLIENT:%global ONLY_CLIENT 0} @@ -135,7 +135,6 @@ Summary: The IPA authentication server Group: System Environment/Base Requires: %{name}-server-common = %{version}-%{release} Requires: %{name}-client = %{version}-%{release} -Requires: %{name}-admintools = %{version}-%{release} Requires: %{name}-common = %{version}-%{release} Requires: python2-ipaserver = %{version}-%{release} Requires: 389-ds-base >= 1.3.5.6 @@ -350,6 +349,13 @@ Provides: %{alt_name}-client = %{version} Conflicts: %{alt_name}-client Obsoletes: %{alt_name}-client < %{version} +Provides: %{alt_name}-admintools = %{version} +Conflicts: %{alt_name}-admintools +Obsoletes: %{alt_name}-admintools < 4.4.1 + +Obsoletes: %{name}-admintools < 4.4.1 +Provides: %{name}-admintools = %{version}-%{release} + %description client IPA is an integrated solution to provide centrally managed Identity (users, hosts, services), Authentication (SSO, 2FA), and Authorization @@ -358,6 +364,7 @@ features for further integration with Linux based clients (SUDO, automount) and integration with Active Directory based infrastructures (Trusts). If your network uses IPA for authentication, this package should be installed on every client machine. +This package provides command-line tools for IPA administrators. %package -n python2-ipaclient @@ -423,26 +430,6 @@ If your network uses IPA for authentication, this package should be installed on every client machine. -%package admintools -Summary: IPA administrative tools -Group: System Environment/Base -BuildArch: noarch -Requires: python2-ipaclient = %{version}-%{release} -Requires: python-ldap - -Provides: %{alt_name}-admintools = %{version} -Conflicts: %{alt_name}-admintools -Obsoletes: %{alt_name}-admintools < %{version} - -%description admintools -IPA is an integrated solution to provide centrally managed Identity (users, -hosts, services), Authentication (SSO, 2FA), and Authorization -(host access control, SELinux user roles, services). The solution provides -features for further integration with Linux based clients (SUDO, automount) -and integration with Active Directory based infrastructures (Trusts). -This package provides command-line tools for IPA administrators. - - %package python-compat Summary: Compatiblity package for Python libraries used by IPA Group: System Environment/Libraries @@ -1293,6 +1280,9 @@ fi %{_sbindir}/ipa-getkeytab %{_sbindir}/ipa-rmkeytab %{_sbindir}/ipa-join +%{_bindir}/ipa +%config %{_sysconfdir}/bash_completion.d +%{_mandir}/man1/ipa.1.gz %{_mandir}/man1/ipa-getkeytab.1.gz %{_mandir}/man1/ipa-rmkeytab.1.gz %{_mandir}/man1/ipa-client-install.1.gz @@ -1352,15 +1342,6 @@ fi %{_mandir}/man5/default.conf.5.gz -%files admintools -%defattr(-,root,root,-) -%doc README Contributors.txt -%license COPYING -%{_bindir}/ipa -%config %{_sysconfdir}/bash_completion.d -%{_mandir}/man1/ipa.1.gz - - %files python-compat %defattr(-,root,root,-) %doc README Contributors.txt -- 2.7.4 From freeipa-github-notification at redhat.com Thu Aug 25 11:10:11 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Thu, 25 Aug 2016 13:10:11 +0200 Subject: [Freeipa-devel] [freeipa PR#20] cert: include CA name in cert command output (opened) In-Reply-To: References: Message-ID: jcholast's pull request #20: "cert: include CA name in cert command output" was opened PR body: """ Include name of the CA that issued a certificate in cert-request, cert-show and cert-find. This allows the caller to call further commands on the cert without having to call ca-find to find the name of the CA. https://fedorahosted.org/freeipa/ticket/6151 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/20 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/20/head:pr20 git checkout pr20 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-20.patch URL: From freeipa-github-notification at redhat.com Thu Aug 25 11:17:34 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Thu, 25 Aug 2016 13:17:34 +0200 Subject: [Freeipa-devel] [freeipa PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (opened) In-Reply-To: References: Message-ID: jcholast's pull request #21: "custodia: include known CA certs in the PKCS#12 file for Dogtag" was opened PR body: """ This fixes CA replica install in a topology upgraded from CA-less to CA-full. https://fedorahosted.org/freeipa/ticket/6207 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/21 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/21/head:pr21 git checkout pr21 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-21.patch URL: From freeipa-github-notification at redhat.com Thu Aug 25 11:26:14 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 25 Aug 2016 13:26:14 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (+ack) In-Reply-To: References: Message-ID: ofayans's pull request #18: "Fixed incorrect sequence of method calls in tasks.py" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/18 From freeipa-github-notification at redhat.com Thu Aug 25 11:29:53 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Thu, 25 Aug 2016 13:29:53 +0200 Subject: [Freeipa-devel] [freeipa PR#22] otptoken: Convert ipatokenotpkey on server (opened) In-Reply-To: References: Message-ID: dkupka's pull request #22: "otptoken: Convert ipatokenotpkey on server" was opened PR body: """ Force client to send the value of ipatokenotpkey as entered by user. Otherwise client encodes the value with base64 before sending to server resulting in using base32(base64(value)) instead of base32(value). https://fedorahosted.org/freeipa/ticket/6247 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/22 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/22/head:pr22 git checkout pr22 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-22.patch URL: From freeipa-github-notification at redhat.com Thu Aug 25 11:32:30 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 25 Aug 2016 13:32:30 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ NACK ``` [Thu Aug 25 13:31:13.597940 2016] [wsgi:error] [pid 130658] Traceback (most recent call last): [Thu Aug 25 13:31:13.597945 2016] [wsgi:error] [pid 130658] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 352, in wsgi_execute [Thu Aug 25 13:31:13.597949 2016] [wsgi:error] [pid 130658] result = self.Command[name](*args, **options) [Thu Aug 25 13:31:13.597952 2016] [wsgi:error] [pid 130658] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ [Thu Aug 25 13:31:13.597955 2016] [wsgi:error] [pid 130658] return self.__do_call(*args, **options) [Thu Aug 25 13:31:13.597959 2016] [wsgi:error] [pid 130658] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call [Thu Aug 25 13:31:13.597967 2016] [wsgi:error] [pid 130658] ret = self.run(*args, **options) [Thu Aug 25 13:31:13.597971 2016] [wsgi:error] [pid 130658] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run [Thu Aug 25 13:31:13.597974 2016] [wsgi:error] [pid 130658] return self.execute(*args, **options) [Thu Aug 25 13:31:13.597978 2016] [wsgi:error] [pid 130658] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 629, in execute [Thu Aug 25 13:31:13.597981 2016] [wsgi:error] [pid 130658] result['cacn'] = ca_obj['cacn'][0] [Thu Aug 25 13:31:13.597984 2016] [wsgi:error] [pid 130658] KeyError: 'cacn' ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/18#issuecomment-242355782 From freeipa-github-notification at redhat.com Thu Aug 25 11:36:29 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 25 Aug 2016 13:36:29 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Please update tests """ See the full comment at https://github.com/freeipa/freeipa/pull/18#issuecomment-242356512 From freeipa-github-notification at redhat.com Thu Aug 25 11:36:40 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Thu, 25 Aug 2016 13:36:40 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (comment) In-Reply-To: References: Message-ID: ofayans commented on a pull request """ @mbasti-rh, are these things related? """ See the full comment at https://github.com/freeipa/freeipa/pull/18#issuecomment-242356557 From freeipa-github-notification at redhat.com Thu Aug 25 11:38:21 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 25 Aug 2016 13:38:21 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Sorry I commented wrong PR :D """ See the full comment at https://github.com/freeipa/freeipa/pull/18#issuecomment-242356876 From freeipa-github-notification at redhat.com Thu Aug 25 11:38:36 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 25 Aug 2016 13:38:36 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ This is still ACK """ See the full comment at https://github.com/freeipa/freeipa/pull/18#issuecomment-242356926 From freeipa-github-notification at redhat.com Thu Aug 25 11:40:06 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Thu, 25 Aug 2016 13:40:06 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (closed) In-Reply-To: References: Message-ID: ofayans's pull request #18: "Fixed incorrect sequence of method calls in tasks.py" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/18 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/18/head:pr18 git checkout pr18 From freeipa-github-notification at redhat.com Thu Aug 25 11:40:12 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 25 Aug 2016 13:40:12 +0200 Subject: [Freeipa-devel] [freeipa PR#20] cert: include CA name in cert command output (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ NACK ``` [Thu Aug 25 13:31:13.597892 2016] [wsgi:error] [pid 130658] ipa: ERROR: non-public: KeyError: 'cacn' [Thu Aug 25 13:31:13.597940 2016] [wsgi:error] [pid 130658] Traceback (most recent call last): [Thu Aug 25 13:31:13.597945 2016] [wsgi:error] [pid 130658] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 352, in wsgi_execute [Thu Aug 25 13:31:13.597949 2016] [wsgi:error] [pid 130658] result = self.Command[name](*args, **options) [Thu Aug 25 13:31:13.597952 2016] [wsgi:error] [pid 130658] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ [Thu Aug 25 13:31:13.597955 2016] [wsgi:error] [pid 130658] return self.__do_call(*args, **options) [Thu Aug 25 13:31:13.597959 2016] [wsgi:error] [pid 130658] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call [Thu Aug 25 13:31:13.597967 2016] [wsgi:error] [pid 130658] ret = self.run(*args, **options) [Thu Aug 25 13:31:13.597971 2016] [wsgi:error] [pid 130658] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run [Thu Aug 25 13:31:13.597974 2016] [wsgi:error] [pid 130658] return self.execute(*args, **options) [Thu Aug 25 13:31:13.597978 2016] [wsgi:error] [pid 130658] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 629, in execute [Thu Aug 25 13:31:13.597981 2016] [wsgi:error] [pid 130658] result['cacn'] = ca_obj['cacn'][0] [Thu Aug 25 13:31:13.597984 2016] [wsgi:error] [pid 130658] KeyError: 'cacn' ``` Please update tests too. """ See the full comment at https://github.com/freeipa/freeipa/pull/20#issuecomment-242357223 From freeipa-github-notification at redhat.com Thu Aug 25 11:49:27 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 25 Aug 2016 13:49:27 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (+pushed) In-Reply-To: References: Message-ID: ofayans's pull request #18: "Fixed incorrect sequence of method calls in tasks.py" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/18 From freeipa-github-notification at redhat.com Thu Aug 25 11:49:33 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 25 Aug 2016 13:49:33 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/fbc9179970ce30ba8c121a3d60b9550ef8f9c06c """ See the full comment at https://github.com/freeipa/freeipa/pull/18#issuecomment-242359000 From freeipa-github-notification at redhat.com Thu Aug 25 11:50:19 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 25 Aug 2016 13:50:19 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ @ofayans This is just mirror repo of fedorahosted , we cannot merge commits here, it has no effect. """ See the full comment at https://github.com/freeipa/freeipa/pull/18#issuecomment-242359169 From mbasti at redhat.com Thu Aug 25 13:31:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Aug 2016 15:31:13 +0200 Subject: [Freeipa-devel] [PATCH 0060] Add --force-join option to ipa-replica-install In-Reply-To: <62dde92d-4978-ae47-abbc-354542ff44a2@redhat.com> References: <84165298-500b-1638-f3b1-a6b20c8f9e63@redhat.com> <44b90a51-6b3c-03fd-86e0-b3c65f626a2a@redhat.com> <378fc422-9620-2b38-cb64-316e4de99e5e@redhat.com> <62dde92d-4978-ae47-abbc-354542ff44a2@redhat.com> Message-ID: <0873eb61-3504-d14d-cd72-a6b350b45c2b@redhat.com> On 10.08.2016 07:53, Stanislav Laznicka wrote: > On 08/10/2016 07:31 AM, Jan Cholasta wrote: >> On 9.8.2016 18:52, Petr Vobornik wrote: >>> On 08/09/2016 04:18 PM, Martin Basti wrote: >>>> >>>> >>>> On 09.08.2016 16:07, Stanislav Laznicka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/6183 >>>>> >>>>> >>>>> >>>> Didn't we agreed that --force-join should be always used (without >>>> extra >>>> replica-install option) >>> >>> +1 >> >> Did we? >> >> IMO the default behavior should be the same as in domain level 0 when >> trying to install replica on an already enrolled host. > That was my impression as well. OK then, I don't like to add mostly useless option, but client install is broken by design so whatever. Martin^2 From freeipa-github-notification at redhat.com Thu Aug 25 13:43:24 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Thu, 25 Aug 2016 15:43:24 +0200 Subject: [Freeipa-devel] [freeipa PR#18] Fixed incorrect sequence of method calls in tasks.py (comment) In-Reply-To: References: Message-ID: ofayans commented on a pull request """ @mbasti-rh oh, I see. Thanks! """ See the full comment at https://github.com/freeipa/freeipa/pull/18#issuecomment-242390863 From freeipa-github-notification at redhat.com Thu Aug 25 14:29:18 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 25 Aug 2016 16:29:18 +0200 Subject: [Freeipa-devel] [freeipa PR#23] Prototype of timerules as LDAP objects (opened) In-Reply-To: References: Message-ID: stlaz's pull request #23: "Prototype of timerules as LDAP objects" was opened PR body: """ Hello, My branch adds the basic capabilities for adding time policies to HBAC rules. The policies are represented as separate objects that I call "time rules" which can be added to each HBAC rule. The policies are based on the iCalendar format. You can read more about the implementation on its design page [Time-Based Account Policies](http://www.freeipa.org/page/V4/Time-Based_Account_Policies). """ See the full pull-request at https://github.com/freeipa/freeipa/pull/23 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/23/head:pr23 git checkout pr23 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-23.patch URL: From freeipa-github-notification at redhat.com Thu Aug 25 14:30:22 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 25 Aug 2016 16:30:22 +0200 Subject: [Freeipa-devel] [freeipa PR#23] Time-Based HBAC Policies (edited) In-Reply-To: References: Message-ID: stlaz's pull request #23: "Time-Based HBAC Policies" was edited See the full pull-request at https://github.com/freeipa/freeipa/pull/23 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/23/head:pr23 git checkout pr23 From slaznick at redhat.com Thu Aug 25 14:56:44 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Thu, 25 Aug 2016 16:56:44 +0200 Subject: [Freeipa-devel] [WIP][PATCH] Time-Based HBAC Policies In-Reply-To: <572C71CC.4000302@redhat.com> References: <56D9935D.9050507@redhat.com> <56E04E38.8080804@redhat.com> <56FBAE4E.6020600@redhat.com> <572C71CC.4000302@redhat.com> Message-ID: <059178e8-8ee5-e265-25f4-bcd247e130d7@redhat.com> On 05/06/2016 12:28 PM, Stanislav Laznicka wrote: > Hello, > > The time rules for FreeIPA effort is now to be found on Github. I > forked FreeIPA and SSSD repos and added the current state of work there. > > https://github.com/stlaz/freeipa/tree/timerules > https://github.com/stlaz/sssd/tree/freeipa-timerules > > Please note that if I'll be making changes to the code it will be done > through rebasing so you may not necessarily be always able to easily > pull the repository. > > I also updated the design so that I may present the current state of > the effort to SSSD developers. The SSSD code is almost finished - some > more tests may be necessary and I still need to do python bindings. > Also, as the pam_hbac module seems to aim for portability, I will need > to discuss the system of getting time zone information on various > systems but the current solution should work just fine on Red Hat-like > and Debian-like distributions. > > In the meantime, I published quite a patch for python-icalendar that > should make it a bit stricter parser but also improve some of its > behavior: https://github.com/collective/icalendar/pull/192. > > Standa > Please note that there's no need to follow this discussion anymore, thanks to the team's GitHub effort all further patches and their discussion moved to https://github.com/freeipa/freeipa/pull/23. From freeipa-github-notification at redhat.com Thu Aug 25 15:47:01 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 25 Aug 2016 17:47:01 +0200 Subject: [Freeipa-devel] [freeipa PR#23] Time-Based HBAC Policies (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ I wrote a few comments. The most serious issue I found was time rule permissions, we must carefully decide what to do now, otherwise it will hurt us in future. Would be nice to provide API tests too :) """ See the full comment at https://github.com/freeipa/freeipa/pull/23#issuecomment-242436313 From blipton at redhat.com Thu Aug 25 19:49:48 2016 From: blipton at redhat.com (Ben Lipton) Date: Thu, 25 Aug 2016 15:49:48 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <4f2f65ed-e525-1f04-f19b-c8a00b23001f@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <20160725111123.qthtarfgcsfbdnzk@redhat.com> <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> <57f0be1e-2915-fa33-d579-f173f1f5d019@redhat.com> <4f2f65ed-e525-1f04-f19b-c8a00b23001f@redhat.com> Message-ID: On 08/23/2016 03:54 AM, Jan Cholasta wrote: > On 8.8.2016 22:23, Ben Lipton wrote: >> On 07/25/2016 07:45 AM, Jan Cholasta wrote: >>> On 25.7.2016 13:11, Alexander Bokovoy wrote: >>>> On Mon, 25 Jul 2016, Jan Cholasta wrote: >>>>> On 20.7.2016 16:05, Ben Lipton wrote: >>>>>> Hi, >>>>>> >>>>>> Thanks very much for the feedback! Some responses below; I hope >>>>>> you'll >>>>>> let me know what you think of my reasoning. >>>>>> >>>>>> >>>>>> On 07/20/2016 04:20 AM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 17.6.2016 00:06, Ben Lipton wrote: >>>>>>>> On 06/14/2016 08:27 AM, Ben Lipton wrote: >>>>>>>>> Hello all, >>>>>>>>> >>>>>>>>> I have written up a design proposal for making certificate >>>>>>>>> requests >>>>>>>>> easier to generate when using alternate certificate profiles: >>>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The use case for this is described in >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4899. I will be >>>>>>>>> working on >>>>>>>>> implementing this design over the next couple of months. If you >>>>>>>>> have >>>>>>>>> the time and interest, please take a look and share any >>>>>>>>> comments or >>>>>>>>> concerns that you have. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Ben >>>>>>>>> >>>>>>>> Just a quick update to say that I've created a new document that >>>>>>>> covers >>>>>>>> the proposed schema additions in a more descriptive way (with >>>>>>>> diagrams!) >>>>>>>> I'm very new to developing with LDAP, so some more experienced >>>>>>>> eyes on >>>>>>>> the proposal would be very helpful, even if you don't have time to >>>>>>>> absorb the full design. Please take a look at >>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> if you have a chance. >>>>>>> >>>>>>> I finally had a chance to take a look at this, here are some >>>>>>> comments: >>>>>>> >>>>>>> 1) I don't like how transformation rules are tied to a particular >>>>>>> helper and have to be duplicated for each of them. They should be >>>>>>> generic and work with any helper, as helpers are just an >>>>>>> implementation detail and their resulting data is the same. >>>>>>> >>>>>>> In fact, I think I would prefer if the CSR was generated using >>>>>>> python-cryptography's CertificateSigningRequestBuilder [1] rather >>>>>>> than >>>>>>> openssl or certutil or any other command line tool. >>>>>>> >>>>>> There are lots of tools that users might want to use to manage their >>>>>> private keys, so I don't know if we can assume that whatever >>>>>> library we >>>>>> prefer will actually be able to access the private key to sign a >>>>>> CSR, >>>>>> which is why I thought it would be useful to support more than one. >>>>> >>>>> python-cryptography has the notion of backends, which allow it to >>>>> support multiple crypto implementations. Upstream it currently >>>>> supports only OpenSSL [2], but some work has been done on PKCS#11 >>>>> backend [3], which provides support for HSMs and soft-tokens (like >>>>> NSS >>>>> databases). >>>>> >>>>> Alternatively, for NSS databases (and other "simple" cases), you can >>>>> generate the private key with python-cryptography using the default >>>>> backend, export it to a file and import the file to the target >>>>> database, so you don't actually need the PKCS#11 backend for them. >>>>> >>>>> So, the only thing that's currently lacking is HSM support, but given >>>>> that we don't support HSMs in IPA nor in certmonger, I don't think >>>>> it's an issue for now. >>>>> >>>>>> The >>>>>> purpose of the mapping rule is to tie together the transformation >>>>>> rules >>>>>> that produce the same data into an object that's >>>>>> implementation-agnostic, so that profiles referencing those rules >>>>>> are >>>>>> automatically compatible with all the helper options. >>>>> >>>>> They are implementation-agnostic, as long as you consider `openssl` >>>>> and `certutil` the only implementations :-) But I don't think this >>>>> solution scales well to other possible implementations. >>>>> >>>>> Anyway, my main grudge is that the transformation rules shouldn't >>>>> really be stored on and processed by the server. The server should >>>>> know the *what* (mapping rules), but not the *how* (transformation >>>>> rules). The *how* is an implementation detail and does not change in >>>>> time, so there's no benefit in handling it on the server. It >>>>> should be >>>>> handled exclusively on the client, which I believe would also make >>>>> the >>>>> whole thing more robust (it would not be possible for a bug on the >>>>> server to break all the clients). >>>> This is a good point. However, for the scope of Ben's project can we >>>> limit it by openssl and certutil support? Otherwise Ben wouldn't be >>>> able >>>> to complete the project in time. >>> >>> I'm fine with that, but I don't think it's up to me :-) >>> >>>> >>>>>> This is turning out to be a common (and, I think, reasonable) >>>>>> reaction >>>>>> to the proposal. It is rather complex, and I worry that it will be >>>>>> difficult to configure. On the other hand, there is some hidden >>>>>> complexity to enabling a simpler config format, as well. One of the >>>>>> goals of the project as it was presented to me was to allow the >>>>>> creation >>>>>> of profiles that add certificate extensions *that FreeIPA doesn't >>>>>> yet >>>>>> know about*. With the current proposal, one only has to add a rule >>>>>> generating text that the helper will understand. >>>>> >>>>> ... which will be possible only as long as the helper understands the >>>>> extension. Which it might not, thus the current proposal works only >>>>> for *some* extensions that FreeIPA doesn't yet support. >>>> We can go ad infinitum here but with any helper implementation, be it >>>> python-cryptography or anything else, you will need to have a support >>>> there as well. >>> >>> My point was that the current proposal is not any better than my >>> proposal in this regard, as neither of them allows one to use an >>> arbitrary extension. >>> >>>> The idea with unknown extensions was to allow mapping >>>> their acceptance to a specific relationship between IPA objects >>>> (optionally) and an input from the CSR. A simplest example would be an >>>> identity rule that would copy an ASN.1 encoded content from the CSR to >>>> the certificate. >>>> >>>> That's on the mapping side, not on the CSR generation side, but it >>>> would >>>> go similarly for the CSR if you would be able to enter unknown but >>>> otherwise correct ASN.1 stream. There is no difference at which helper >>>> type we are talking about because all of them support inserting ASN.1 >>>> content. >>>> >>>>>> With your suggestion, >>>>>> if there's a mapping between "san_directoryname" and the >>>>>> corresponding >>>>>> API calls or configuration lines, we need some way for users to >>>>>> augment >>>>>> that mapping without changing the code. If there's no mapping, and >>>>>> it's >>>>>> just done with text processing, we need enough in the config >>>>>> format to >>>>>> be able to generate fairly complex structures: >>>>>> >>>>>> builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>>>>> builder = >>>>>> builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>>>>> >>>>>> >>>>>> >>>>>> x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False) >>>>>> >>>>>> and we need to do it without it being equivalent to calling >>>>>> eval() on >>>>>> the config attributes. I'm not sure how to achieve this (is it >>>>>> safe to >>>>>> call getattr(x509, extensiontype)(value) where extensiontype and >>>>>> value >>>>>> are user-specified?) and it definitely would have to be tied to a >>>>>> particular library/tool. >>>>> >>>>> As I pointed out above, this needs to be figured out for the generic >>>>> case for both the current proposal and my suggestion. >> I have a proof of concept[1] for using openssl-based rules to add a >> subject alt name extension without using openssl's knowledge of that >> extension. It's not extremely pretty, and it took some trial and error, >> but no code changes. So, I think this actually is a difference between >> the two proposals. > > With the obvious catch being that it works only with OpenSSL, which > might not work for everyone, e.g. when using HSMs or SmartCards, due > to a limited PKCS#11 support in OpenSSL. Very true. Even certutil's equivalent feature (--extGeneric) doesn't seem like it would work very well in this context, as you are supposed to pass in an already-encoded extension, so text-based templating wouldn't be able to do much. > >> >> Next we have the easy case, extensions that we as FreeIPA developers >> know are important and build support for. For these, the two proposals >> work equivalently well, but yours is simpler to configure because the >> knowledge of how to make a san_rfc822name is built into the library >> instead of being stored on the server as a set of rules. >> >> Finally, we have the case of extensions that are known to the helper, >> but not to FreeIPA. In the existing proposal, new rules can be written >> to support these extensions under a particular helper. Further, those >> rules can be used by reference in many profiles, reducing duplication of >> effort/data/errors. >> >> As I understand it, the main objections in this thread are that >> transformation rules are implementation (i.e. helper) specific data >> stored in the IPA server, and that the system has several levels of >> schema when it could just embed rules in the profile. But without >> helper-specific rules, administrators could not take advantage of the >> additional extensions supported by the helper they are using. > > There is *no* advantage in forcing the user to choose between helpers > which differ only in the set of limitations on the CSR they are able > to produce. The user should specify a) where the private key is > located and b) what profile to use, and that's it, it should just work. Ok, this is a good point about usability. The user creating the CSR shouldn't have to care about helpers, and I agree that the current way they are exposed is clunky. I do think that an administrator creating custom rules might want to take advantage of a helper, so they wouldn't need to understand the ASN.1 representation of their chosen certificate extension. Of course, the desired extension might not be supported by the helper either. Since I don't know what specific extensions people will want to use this for, I don't know how to balance the better administrator experience of adding extensions via a helper with the limited extension support. The original reason we arrived at the concept of "helpers" was to support different ways of getting at private keys, but perhaps this should not be the concern of the CSR data generator. In your opinion, would it be sufficient to support just one key format (PKCS#12? PEM?) and let the user deal with putting those keys into whatever formats/databases they need? If that's ok, maybe we can stop having *multiple* helpers, but if we want to replace helpers entirely I'm still not certain what to replace them with. > >> And >> without the separation of profiles from mapping rules in the schema, >> rules would need to be copy+pasted among profiles, and grouping rules >> with the same effect under different helpers would be much uglier. We >> can and should discuss whether these are the right tradeoffs, but this >> is where those decisions came from. >> >>>>> >>>>> OTOH, I think we could use GSER encoding of the extension value: >>>>> >>>>> { rfc822Name:"user at example.com", >>>>> directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } >>>> GSER is not really used widely and does not have standardized encoding >>>> rules beyond its own definition. If you want to allow transformation >>>> rules in GSER that mention existing content in IPA objects, you would >>>> need to deal with templating anyway. At this point it becomes >>>> irrelevant >>>> what you are templating, though. >>> >>> True, but the goal here is not to avoid templating, but rather to >>> avoid implementation-specific bits on the server, and GSER is the only >>> thing that is textual, implementation-neutral and, as a bonus, >>> standardized. >>> >> As I said elsewhere, we could use GSER as a textual output format >> instead of openssl or certutil, but it still needs its own "helper" to >> build the CSR, and unlike the other options, it seems like we might need >> to implement that helper. I'm not sure it's fair to call it >> implementation-neutral if no implementation exists yet :) > > Right. Like I said, using GSER was just a quick idea off the top of my > head. I would actually rather use some sort of data structure > templating rather than textual templating on top of any kind of > textual representation of said data structures. I don't know if there > is such a thing, though. This sounds interesting, can you give an example of what this might look like? I learned that there's also an XML encoding for ASN.1, XER, but that's still a textual representation and we'd have to insert the data textually. It doesn't seem to be supported by any python libraries, either, but it does look like it's supported by the asn1 compiler in the IPA source distribution. I could imagine an implementation that builds an XML representation of the CSR via python templating, then makes a signed CSR out of it in C. I'm a little concerned about it because it would have to implement the whole CSR structure from scratch, but is this a prototype that you'd be interested in seeing? From rcritten at redhat.com Thu Aug 25 20:11:13 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 25 Aug 2016 16:11:13 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <20160725111123.qthtarfgcsfbdnzk@redhat.com> <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> <57f0be1e-2915-fa33-d579-f173f1f5d019@redhat.com> <4f2f65ed-e525-1f04-f19b-c8a00b23001f@redhat.com> Message-ID: <57BF50E1.8030209@redhat.com> Ben Lipton wrote: > On 08/23/2016 03:54 AM, Jan Cholasta wrote: >> On 8.8.2016 22:23, Ben Lipton wrote: >>> On 07/25/2016 07:45 AM, Jan Cholasta wrote: >>>> On 25.7.2016 13:11, Alexander Bokovoy wrote: >>>>> On Mon, 25 Jul 2016, Jan Cholasta wrote: >>>>>> On 20.7.2016 16:05, Ben Lipton wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Thanks very much for the feedback! Some responses below; I hope >>>>>>> you'll >>>>>>> let me know what you think of my reasoning. >>>>>>> >>>>>>> >>>>>>> On 07/20/2016 04:20 AM, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 17.6.2016 00:06, Ben Lipton wrote: >>>>>>>>> On 06/14/2016 08:27 AM, Ben Lipton wrote: >>>>>>>>>> Hello all, >>>>>>>>>> >>>>>>>>>> I have written up a design proposal for making certificate >>>>>>>>>> requests >>>>>>>>>> easier to generate when using alternate certificate profiles: >>>>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The use case for this is described in >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4899. I will be >>>>>>>>>> working on >>>>>>>>>> implementing this design over the next couple of months. If you >>>>>>>>>> have >>>>>>>>>> the time and interest, please take a look and share any >>>>>>>>>> comments or >>>>>>>>>> concerns that you have. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Ben >>>>>>>>>> >>>>>>>>> Just a quick update to say that I've created a new document that >>>>>>>>> covers >>>>>>>>> the proposed schema additions in a more descriptive way (with >>>>>>>>> diagrams!) >>>>>>>>> I'm very new to developing with LDAP, so some more experienced >>>>>>>>> eyes on >>>>>>>>> the proposal would be very helpful, even if you don't have time to >>>>>>>>> absorb the full design. Please take a look at >>>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> if you have a chance. >>>>>>>> >>>>>>>> I finally had a chance to take a look at this, here are some >>>>>>>> comments: >>>>>>>> >>>>>>>> 1) I don't like how transformation rules are tied to a particular >>>>>>>> helper and have to be duplicated for each of them. They should be >>>>>>>> generic and work with any helper, as helpers are just an >>>>>>>> implementation detail and their resulting data is the same. >>>>>>>> >>>>>>>> In fact, I think I would prefer if the CSR was generated using >>>>>>>> python-cryptography's CertificateSigningRequestBuilder [1] rather >>>>>>>> than >>>>>>>> openssl or certutil or any other command line tool. >>>>>>>> >>>>>>> There are lots of tools that users might want to use to manage their >>>>>>> private keys, so I don't know if we can assume that whatever >>>>>>> library we >>>>>>> prefer will actually be able to access the private key to sign a >>>>>>> CSR, >>>>>>> which is why I thought it would be useful to support more than one. >>>>>> >>>>>> python-cryptography has the notion of backends, which allow it to >>>>>> support multiple crypto implementations. Upstream it currently >>>>>> supports only OpenSSL [2], but some work has been done on PKCS#11 >>>>>> backend [3], which provides support for HSMs and soft-tokens (like >>>>>> NSS >>>>>> databases). >>>>>> >>>>>> Alternatively, for NSS databases (and other "simple" cases), you can >>>>>> generate the private key with python-cryptography using the default >>>>>> backend, export it to a file and import the file to the target >>>>>> database, so you don't actually need the PKCS#11 backend for them. >>>>>> >>>>>> So, the only thing that's currently lacking is HSM support, but given >>>>>> that we don't support HSMs in IPA nor in certmonger, I don't think >>>>>> it's an issue for now. >>>>>> >>>>>>> The >>>>>>> purpose of the mapping rule is to tie together the transformation >>>>>>> rules >>>>>>> that produce the same data into an object that's >>>>>>> implementation-agnostic, so that profiles referencing those rules >>>>>>> are >>>>>>> automatically compatible with all the helper options. >>>>>> >>>>>> They are implementation-agnostic, as long as you consider `openssl` >>>>>> and `certutil` the only implementations :-) But I don't think this >>>>>> solution scales well to other possible implementations. >>>>>> >>>>>> Anyway, my main grudge is that the transformation rules shouldn't >>>>>> really be stored on and processed by the server. The server should >>>>>> know the *what* (mapping rules), but not the *how* (transformation >>>>>> rules). The *how* is an implementation detail and does not change in >>>>>> time, so there's no benefit in handling it on the server. It >>>>>> should be >>>>>> handled exclusively on the client, which I believe would also make >>>>>> the >>>>>> whole thing more robust (it would not be possible for a bug on the >>>>>> server to break all the clients). >>>>> This is a good point. However, for the scope of Ben's project can we >>>>> limit it by openssl and certutil support? Otherwise Ben wouldn't be >>>>> able >>>>> to complete the project in time. >>>> >>>> I'm fine with that, but I don't think it's up to me :-) >>>> >>>>> >>>>>>> This is turning out to be a common (and, I think, reasonable) >>>>>>> reaction >>>>>>> to the proposal. It is rather complex, and I worry that it will be >>>>>>> difficult to configure. On the other hand, there is some hidden >>>>>>> complexity to enabling a simpler config format, as well. One of the >>>>>>> goals of the project as it was presented to me was to allow the >>>>>>> creation >>>>>>> of profiles that add certificate extensions *that FreeIPA doesn't >>>>>>> yet >>>>>>> know about*. With the current proposal, one only has to add a rule >>>>>>> generating text that the helper will understand. >>>>>> >>>>>> ... which will be possible only as long as the helper understands the >>>>>> extension. Which it might not, thus the current proposal works only >>>>>> for *some* extensions that FreeIPA doesn't yet support. >>>>> We can go ad infinitum here but with any helper implementation, be it >>>>> python-cryptography or anything else, you will need to have a support >>>>> there as well. >>>> >>>> My point was that the current proposal is not any better than my >>>> proposal in this regard, as neither of them allows one to use an >>>> arbitrary extension. >>>> >>>>> The idea with unknown extensions was to allow mapping >>>>> their acceptance to a specific relationship between IPA objects >>>>> (optionally) and an input from the CSR. A simplest example would be an >>>>> identity rule that would copy an ASN.1 encoded content from the CSR to >>>>> the certificate. >>>>> >>>>> That's on the mapping side, not on the CSR generation side, but it >>>>> would >>>>> go similarly for the CSR if you would be able to enter unknown but >>>>> otherwise correct ASN.1 stream. There is no difference at which helper >>>>> type we are talking about because all of them support inserting ASN.1 >>>>> content. >>>>> >>>>>>> With your suggestion, >>>>>>> if there's a mapping between "san_directoryname" and the >>>>>>> corresponding >>>>>>> API calls or configuration lines, we need some way for users to >>>>>>> augment >>>>>>> that mapping without changing the code. If there's no mapping, and >>>>>>> it's >>>>>>> just done with text processing, we need enough in the config >>>>>>> format to >>>>>>> be able to generate fairly complex structures: >>>>>>> >>>>>>> builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>>>>>> builder = >>>>>>> builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>>>>>> >>>>>>> >>>>>>> >>>>>>> x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False) >>>>>>> >>>>>>> and we need to do it without it being equivalent to calling >>>>>>> eval() on >>>>>>> the config attributes. I'm not sure how to achieve this (is it >>>>>>> safe to >>>>>>> call getattr(x509, extensiontype)(value) where extensiontype and >>>>>>> value >>>>>>> are user-specified?) and it definitely would have to be tied to a >>>>>>> particular library/tool. >>>>>> >>>>>> As I pointed out above, this needs to be figured out for the generic >>>>>> case for both the current proposal and my suggestion. >>> I have a proof of concept[1] for using openssl-based rules to add a >>> subject alt name extension without using openssl's knowledge of that >>> extension. It's not extremely pretty, and it took some trial and error, >>> but no code changes. So, I think this actually is a difference between >>> the two proposals. >> >> With the obvious catch being that it works only with OpenSSL, which >> might not work for everyone, e.g. when using HSMs or SmartCards, due >> to a limited PKCS#11 support in OpenSSL. > > Very true. Even certutil's equivalent feature (--extGeneric) doesn't > seem like it would work very well in this context, as you are supposed > to pass in an already-encoded extension, so text-based templating > wouldn't be able to do much. Yeah, I struggled with this myself. I ended up writing a pyasn1 script to generate the extension I needed, wrote that to a file, and passed it to certutil using: --extGeneric 2.5.29.17:not-critical:/path/to/msupn.der >> >>> >>> Next we have the easy case, extensions that we as FreeIPA developers >>> know are important and build support for. For these, the two proposals >>> work equivalently well, but yours is simpler to configure because the >>> knowledge of how to make a san_rfc822name is built into the library >>> instead of being stored on the server as a set of rules. >>> >>> Finally, we have the case of extensions that are known to the helper, >>> but not to FreeIPA. In the existing proposal, new rules can be written >>> to support these extensions under a particular helper. Further, those >>> rules can be used by reference in many profiles, reducing duplication of >>> effort/data/errors. >>> >>> As I understand it, the main objections in this thread are that >>> transformation rules are implementation (i.e. helper) specific data >>> stored in the IPA server, and that the system has several levels of >>> schema when it could just embed rules in the profile. But without >>> helper-specific rules, administrators could not take advantage of the >>> additional extensions supported by the helper they are using. >> >> There is *no* advantage in forcing the user to choose between helpers >> which differ only in the set of limitations on the CSR they are able >> to produce. The user should specify a) where the private key is >> located and b) what profile to use, and that's it, it should just work. > Ok, this is a good point about usability. The user creating the CSR > shouldn't have to care about helpers, and I agree that the current way > they are exposed is clunky. I do think that an administrator creating > custom rules might want to take advantage of a helper, so they wouldn't > need to understand the ASN.1 representation of their chosen certificate > extension. Of course, the desired extension might not be supported by > the helper either. Since I don't know what specific extensions people > will want to use this for, I don't know how to balance the better > administrator experience of adding extensions via a helper with the > limited extension support. > > The original reason we arrived at the concept of "helpers" was to > support different ways of getting at private keys, but perhaps this > should not be the concern of the CSR data generator. In your opinion, > would it be sufficient to support just one key format (PKCS#12? PEM?) > and let the user deal with putting those keys into whatever > formats/databases they need? If that's ok, maybe we can stop having > *multiple* helpers, but if we want to replace helpers entirely I'm still > not certain what to replace them with. I'd just add an option to specify the output format, e.g PEM, NSS, Java keystore, PKCS#12, whatever.You can probably get away with the first two for starters. Different output format is going to mean different options but that is probably not a big deal. Remember that the private key will be at rest for some period of time while the CSR is being approved. The key needs to be protected at that time. rob >> >>> And >>> without the separation of profiles from mapping rules in the schema, >>> rules would need to be copy+pasted among profiles, and grouping rules >>> with the same effect under different helpers would be much uglier. We >>> can and should discuss whether these are the right tradeoffs, but this >>> is where those decisions came from. >>> >>>>>> >>>>>> OTOH, I think we could use GSER encoding of the extension value: >>>>>> >>>>>> { rfc822Name:"user at example.com", >>>>>> directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } >>>>> GSER is not really used widely and does not have standardized encoding >>>>> rules beyond its own definition. If you want to allow transformation >>>>> rules in GSER that mention existing content in IPA objects, you would >>>>> need to deal with templating anyway. At this point it becomes >>>>> irrelevant >>>>> what you are templating, though. >>>> >>>> True, but the goal here is not to avoid templating, but rather to >>>> avoid implementation-specific bits on the server, and GSER is the only >>>> thing that is textual, implementation-neutral and, as a bonus, >>>> standardized. >>>> >>> As I said elsewhere, we could use GSER as a textual output format >>> instead of openssl or certutil, but it still needs its own "helper" to >>> build the CSR, and unlike the other options, it seems like we might need >>> to implement that helper. I'm not sure it's fair to call it >>> implementation-neutral if no implementation exists yet :) >> >> Right. Like I said, using GSER was just a quick idea off the top of my >> head. I would actually rather use some sort of data structure >> templating rather than textual templating on top of any kind of >> textual representation of said data structures. I don't know if there >> is such a thing, though. > > This sounds interesting, can you give an example of what this might look > like? > > I learned that there's also an XML encoding for ASN.1, XER, but that's > still a textual representation and we'd have to insert the data > textually. It doesn't seem to be supported by any python libraries, > either, but it does look like it's supported by the asn1 compiler in the > IPA source distribution. I could imagine an implementation that builds > an XML representation of the CSR via python templating, then makes a > signed CSR out of it in C. I'm a little concerned about it because it > would have to implement the whole CSR structure from scratch, but is > this a prototype that you'd be interested in seeing? > From ftweedal at redhat.com Fri Aug 26 02:19:07 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 26 Aug 2016 12:19:07 +1000 Subject: [Freeipa-devel] [PATCH] 0102..0105 Better handling for cert-request to disabled CA Message-ID: <20160826021907.GN3877@dhcp-40-8.bne.redhat.com> The attached patches add better handling of cert-request failure due to target CA being disabled (#6260). To do this, rather than go and do extra work in Dogtag that we would depend on, instead I bite the bullet and refactor ra.request_certificate to use the Dogtag REST API, which correctly responds with status 409 in this case. Switching RA to Dogtag REST API is an old ticket (#3437) so these patches address it in part, and show the way forward for the rest of it. These patches don't technically depend on patch 0101 which adds the ca-enable and ca-disable commands, but 0101 may help for testing :) Thanks, Fraser -------------- next part -------------- From 97501fad9bfe64af076a8c1a65bd732ac265b940 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 26 Aug 2016 08:59:10 +1000 Subject: [PATCH 102/105] Allow Dogtag RestClient to perform requests without logging in Currently the Dogtag RestClient '_ssldo' method requires a session cookie unconditionally, however, not all REST methods require a session: some do not require authentication at all, and some will authenticate the agent on the fly. To avoid unnecessary login/logout requests via the context manager, add the 'use_session' keyword argument to '_ssldo'. It defaults to 'True' to preserve existing behaviour (session required) but a caller can set to 'False' to avoid the requirement. Part of: https://fedorahosted.org/freeipa/ticket/6260 Part of: https://fedorahosted.org/freeipa/ticket/3473 --- ipaserver/plugins/dogtag.py | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 01e5f1383ee135696a8e968793863ce964025094..ac3fa40f80f7c23ab5dceda5e20a33812ff82a21 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -2071,26 +2071,40 @@ class RestClient(Backend): ) self.cookie = None - def _ssldo(self, method, path, headers=None, body=None): + def _ssldo(self, method, path, headers=None, body=None, use_session=True): """ - :param url: The URL to post to. - :param kw: Keyword arguments to encode into POST body. + Perform an HTTPS request. + + ``method`` + HTTP method to use + ``path`` + Path component. This will *extend* the path defined for + the class (if any). + ``headers`` + Additional headers to include in the request. + ``body`` + Request body. + ``use_session`` + If ``True``, session cookie is added to request (client + must be logged in). + :return: (http_status, http_headers, http_body) as (integer, dict, str) - Perform an HTTPS request """ - if self.cookie is None: - raise errors.RemoteRetrieveError( - reason=_("REST API is not logged in.")) - headers = headers or {} - headers['Cookie'] = self.cookie + if use_session: + if self.cookie is None: + raise errors.RemoteRetrieveError( + reason=_("REST API is not logged in.")) + headers['Cookie'] = self.cookie + + resource = '/ca/rest' + if self.path is not None: + resource = os.path.join(resource, self.path) if path is not None: - resource = os.path.join('/ca/rest', self.path, path) - else: - resource = os.path.join('/ca/rest', self.path) + resource = os.path.join(resource, path) # perform main request status, resp_headers, resp_body = dogtag.https_request( -- 2.5.5 -------------- next part -------------- From 5b8c67c2f293cea32f0a492069bab4ce055ed8fa Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 26 Aug 2016 09:04:04 +1000 Subject: [PATCH 103/105] Add HTTPRequestError class Currently, HTTP requests that respond with status not in the 2xx range raise RemoteRetrieveError. The exception includes no information about the response status. Add the 'HTTPRequestError' class which extends 'RemoteRequestError' with an attribute for the response status, and update the Dogtag RestClient to raise the new error. Part of: https://fedorahosted.org/freeipa/ticket/6260 Part of: https://fedorahosted.org/freeipa/ticket/3473 --- ipalib/errors.py | 13 +++++++++++++ ipaserver/plugins/dogtag.py | 3 ++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/ipalib/errors.py b/ipalib/errors.py index 4cc4455b0abf7d2b1366e1ce6dbb3762bc551cc6..268376f513e7ba9dbfbffaa103002ae4859ecc47 100644 --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -1406,6 +1406,19 @@ class OperationNotSupportedForPrincipalType(ExecutionError): '%(operation)s is not supported for %(principal_type)s principals') +class HTTPRequestError(RemoteRetrieveError): + """ + **4035** Raised when an HTTP request fails. Includes the response + status in the ``status`` attribute. + """ + + errno = 4035 + + def __init__(self, status=None, **kw): + assert status is not None + super(HTTPRequestError, self).__init__(status=status, **kw) + + class BuiltinError(ExecutionError): """ **4100** Base class for builtin execution errors (*4100 - 4199*). diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index ac3fa40f80f7c23ab5dceda5e20a33812ff82a21..4f85c921040fa5065662d6e4963c4cddafd4f33d 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -2115,7 +2115,8 @@ class RestClient(Backend): ) if status < 200 or status >= 300: explanation = self._parse_dogtag_error(resp_body) or '' - raise errors.RemoteRetrieveError( + raise errors.HTTPRequestError( + status=status, reason=_('Non-2xx response from CA REST API: %(status)d. %(explanation)s') % {'status': status, 'explanation': explanation} ) -- 2.5.5 -------------- next part -------------- From 70850a04ba41aba9065fb9b66a45476d35e4054d Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 26 Aug 2016 10:02:21 +1000 Subject: [PATCH 104/105] Use Dogtag REST API for certificate requests The Dogtag REST API gives better responses statuses than the RPC API and properly reports failure due to disabled CA (status 409). Make 'ra' extend 'RestClient' and refactor the 'request_certificate' method to use Dogtag's REST API. Part of: https://fedorahosted.org/freeipa/ticket/6260 Part of: https://fedorahosted.org/freeipa/ticket/3473 --- install/conf/ipa-pki-proxy.conf | 4 +- ipaserver/plugins/dogtag.py | 502 ++++++++++++++++------------------------ 2 files changed, 206 insertions(+), 300 deletions(-) diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 545f21253ec8895397e43a3c9637956e94f40293..b48a3020d22df623fab471b2367adfd5d521544c 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -1,4 +1,4 @@ -# VERSION 9 - DO NOT REMOVE THIS LINE +# VERSION 10 - DO NOT REMOVE THIS LINE ProxyRequests Off @@ -27,7 +27,7 @@ ProxyRequests Off # matches for CA REST API - + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient optional ProxyPassMatch ajp://localhost:$DOGTAG_PORT diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 4f85c921040fa5065662d6e4963c4cddafd4f33d..db2bbc20e12be108cf02387e1eecfff60d34cd67 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -566,83 +566,6 @@ def parse_error_response_xml(doc): return response -def parse_profile_submit_result_xml(doc): - ''' - :param doc: The root node of the xml document to parse - :returns: result dict - :except ValueError: - - CMS returns an error code and an array of request records. - - This function returns a response dict with the following format: - {'error_code' : int, 'requests' : [{}]} - - The mapping of fields and data types is illustrated in the following table. - - If the error_code is not SUCCESS then the response dict will have the - contents described in `parse_error_response_xml`. - - +--------------------+----------------+------------------------+---------------+ - |cms name |cms type |result name |result type | - +====================+================+========================+===============+ - |Status |int |error_code |int | - +--------------------+----------------+------------------------+---------------+ - |Requests[].Id |string |requests[].request_id |unicode | - +--------------------+----------------+------------------------+---------------+ - |Requests[].SubjectDN|string |requests[].subject |unicode | - +--------------------+----------------+------------------------+---------------+ - |Requests[].serialno |BigInteger |requests[].serial_number|int|long | - +--------------------+----------------+------------------------+---------------+ - |Requests[].b64 |string |requests[].certificate |unicode [1]_ | - +--------------------+----------------+------------------------+---------------+ - |Requests[].pkcs7 |string | | | - +--------------------+----------------+------------------------+---------------+ - - .. [1] Base64 encoded - - ''' - - error_code = get_error_code_xml(doc) - if error_code != CMS_SUCCESS: - response = parse_error_response_xml(doc) - return response - - response = {} - response['error_code'] = error_code - - requests = [] - response['requests'] = requests - - for request in doc.xpath('//XMLResponse/Requests[*]/Request'): - response_request = {} - requests.append(response_request) - - request_id = request.xpath('Id[1]') - if len(request_id) == 1: - request_id = etree.tostring(request_id[0], method='text', - encoding=unicode).strip() - response_request['request_id'] = request_id - - subject_dn = request.xpath('SubjectDN[1]') - if len(subject_dn) == 1: - subject_dn = etree.tostring(subject_dn[0], method='text', - encoding=unicode).strip() - response_request['subject'] = subject_dn - - serial_number = request.xpath('serialno[1]') - if len(serial_number) == 1: - serial_number = int(serial_number[0].text, 16) # parse as hex - response_request['serial_number'] = serial_number - response['serial_number_hex'] = u'0x%X' % serial_number - - certificate = request.xpath('b64[1]') - if len(certificate) == 1: - certificate = etree.tostring(certificate[0], method='text', - encoding=unicode).strip() - response_request['certificate'] = certificate - - return response - def parse_check_request_result_xml(doc): ''' @@ -1286,32 +1209,161 @@ from ipaplatform.paths import paths register = Registry() +class RestClient(Backend): + """Simple Dogtag REST client to be subclassed by other backends. + + This class is a context manager. Authenticated calls must be + executed in a ``with`` suite:: + + @register() + class ra_certprofile(RestClient): + path = 'profile' + ... + + with api.Backend.ra_certprofile as profile_api: + # REST client is now logged in + profile_api.create_profile(...) + + """ + path = None + + @staticmethod + def _parse_dogtag_error(body): + try: + return pki.PKIException.from_json(json.loads(body)) + except Exception: + return None + + def __init__(self, api): + if api.env.in_tree: + self.sec_dir = api.env.dot_ipa + os.sep + 'alias' + self.pwd_file = self.sec_dir + os.sep + '.pwd' + else: + self.sec_dir = paths.HTTPD_ALIAS_DIR + self.pwd_file = paths.ALIAS_PWDFILE_TXT + self.noise_file = self.sec_dir + os.sep + '.noise' + self.ipa_key_size = "2048" + self.ipa_certificate_nickname = "ipaCert" + self.ca_certificate_nickname = "caCert" + self._read_password() + super(RestClient, self).__init__(api) + + # session cookie + self.override_port = None + self.cookie = None + + def _read_password(self): + try: + with open(self.pwd_file) as f: + self.password = f.readline().strip() + except IOError: + self.password = '' + + @cachedproperty + def ca_host(self): + """ + :return: host + as str + + Select our CA host. + """ + ldap2 = self.api.Backend.ldap2 + if host_has_service(api.env.ca_host, ldap2, "CA"): + return api.env.ca_host + if api.env.host != api.env.ca_host: + if host_has_service(api.env.host, ldap2, "CA"): + return api.env.host + host = select_any_master(ldap2) + if host: + return host + else: + return api.env.ca_host + + def __enter__(self): + """Log into the REST API""" + if self.cookie is not None: + return + status, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.override_port or self.env.ca_agent_port, + '/ca/rest/account/login', + self.sec_dir, self.password, self.ipa_certificate_nickname, + method='GET' + ) + cookies = ipapython.cookie.Cookie.parse(resp_headers.get('set-cookie', '')) + if status != 200 or len(cookies) == 0: + raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) + self.cookie = str(cookies[0]) + return self + + def __exit__(self, exc_type, exc_value, traceback): + """Log out of the REST API""" + dogtag.https_request( + self.ca_host, self.override_port or self.env.ca_agent_port, + '/ca/rest/account/logout', + self.sec_dir, self.password, self.ipa_certificate_nickname, + method='GET' + ) + self.cookie = None + + def _ssldo(self, method, path, headers=None, body=None, use_session=True): + """ + Perform an HTTPS request. + + ``method`` + HTTP method to use + ``path`` + Path component. This will *extend* the path defined for + the class (if any). + ``headers`` + Additional headers to include in the request. + ``body`` + Request body. + ``use_session`` + If ``True``, session cookie is added to request (client + must be logged in). + + :return: (http_status, http_headers, http_body) + as (integer, dict, str) + + """ + headers = headers or {} + + if use_session: + if self.cookie is None: + raise errors.RemoteRetrieveError( + reason=_("REST API is not logged in.")) + headers['Cookie'] = self.cookie + + resource = '/ca/rest' + if self.path is not None: + resource = os.path.join(resource, self.path) + if path is not None: + resource = os.path.join(resource, path) + + # perform main request + status, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.override_port or self.env.ca_agent_port, + resource, + self.sec_dir, self.password, self.ipa_certificate_nickname, + method=method, headers=headers, body=body + ) + if status < 200 or status >= 300: + explanation = self._parse_dogtag_error(resp_body) or '' + raise errors.HTTPRequestError( + status=status, + reason=_('Non-2xx response from CA REST API: %(status)d. %(explanation)s') + % {'status': status, 'explanation': explanation} + ) + return (status, resp_headers, resp_body) + + @register() -class ra(rabase.rabase): +class ra(rabase.rabase, RestClient): """ Request Authority backend plugin. """ DEFAULT_PROFILE = dogtag.DEFAULT_PROFILE - def __init__(self, api): - if api.env.in_tree: - self.sec_dir = api.env.dot_ipa + os.sep + 'alias' - self.pwd_file = self.sec_dir + os.sep + '.pwd' - else: - self.sec_dir = paths.HTTPD_ALIAS_DIR - self.pwd_file = paths.ALIAS_PWDFILE_TXT - self.noise_file = self.sec_dir + os.sep + '.noise' - self.ipa_key_size = "2048" - self.ipa_certificate_nickname = "ipaCert" - self.ca_certificate_nickname = "caCert" - try: - f = open(self.pwd_file, "r") - self.password = f.readline().strip() - f.close() - except IOError: - self.password = '' - super(ra, self).__init__(api) - def raise_certificate_operation_error(self, func_name, err_msg=None, detail=None): """ :param func_name: function name where error occurred @@ -1564,75 +1616,77 @@ class ra(rabase.rabase): Submit certificate signing request. - The command returns a dict with these possible key/value pairs. - Some key/value pairs may be absent. + The command returns a dict with these key/value pairs: - +---------------+---------------+---------------+ - |result name |result type |comments | - +===============+===============+===============+ - |serial_number |unicode [1]_ | | - +---------------+---------------+---------------+ - |certificate |unicode [2]_ | | - +---------------+---------------+---------------+ - |request_id |unicode | | - +---------------+---------------+---------------+ - |subject |unicode | | - +---------------+---------------+---------------+ - - .. [1] Passed through XMLRPC as decimal string. Can convert to - optimal integer type (int or long) via int(serial_number) - - .. [2] Base64 encoded + ``serial_number`` + ``unicode``, decimal representation + ``serial_number_hex`` + ``unicode``, hex representation with ``'0x'`` leader + ``certificate`` + ``unicode``, base64-encoded DER + ``request_id`` + ``unicode``, decimal representation """ self.debug('%s.request_certificate()', type(self).__name__) # Call CMS - kw = dict( - profileId=profile_id, - cert_request_type=request_type, - cert_request=csr, - xml='true') + template = ''' + + {profile} + + certReqInputImpl + + {req_type} + + + {req} + + + ''' + data = template.format( + profile=profile_id, + req_type=request_type, + req=csr, + ) + + path = 'certrequests' if ca_id: - kw['authorityId'] = ca_id + path += '?issuer-id={}'.format(ca_id) - http_status, http_headers, http_body = self._sslget( - '/ca/eeca/ca/profileSubmitSSLClient', self.env.ca_ee_port, **kw) - # Parse and handle errors - if http_status != 200: - self.raise_certificate_operation_error('request_certificate', - detail=http_status) - - parse_result = self.get_parse_result_xml(http_body, parse_profile_submit_result_xml) - # Note different status return, it's not request_status, it's error_code - error_code = parse_result['error_code'] - if error_code != CMS_SUCCESS: - self.raise_certificate_operation_error('request_certificate', - cms_error_code_to_string(error_code), - parse_result.get('error_string')) + http_status, http_headers, http_body = self._ssldo( + 'POST', path, + headers={ + 'Content-Type': 'application/xml', + 'Accept': 'application/json', + }, + body=data, + use_session=False, + ) + try: + resp_obj = json.loads(http_body) + except: + raise errors.RemoteRetrieveError(reason=_("Response from CA was not valid JSON")) # Return command result cmd_result = {} - # FIXME: should we return all the requests instead of just the first one? - if len(parse_result['requests']) < 1: + entries = resp_obj.get('entries', []) + + # ipa cert-request only handles a single PKCS #10 request so + # there's only one certinfo in the result. + if len(entries) < 1: return cmd_result - request = parse_result['requests'][0] + certinfo = entries[0] - if 'serial_number' in request: - # see module documentation concerning serial numbers and XMLRPC - cmd_result['serial_number'] = unicode(request['serial_number']) - cmd_result['serial_number_hex'] = u'0x%X' % request['serial_number'] + if 'certId' in certinfo: + cmd_result = self.get_certificate(certinfo['certId']) + cert = cmd_result['certificate'].splitlines() + cmd_result['certificate'] = ''.join(cert.splitlines()) - if 'certificate' in request: - cmd_result['certificate'] = request['certificate'] - - if 'request_id' in request: - cmd_result['request_id'] = request['request_id'] - - if 'subject' in request: - cmd_result['subject'] = request['subject'] + if 'requestURL' in certinfo: + cmd_result['request_id'] = certinfo['requestURL'].split('/')[-1] return cmd_result @@ -1975,154 +2029,6 @@ class kra(Backend): return KRAClient(connection, crypto) -class RestClient(Backend): - """Simple Dogtag REST client to be subclassed by other backends. - - This class is a context manager. Authenticated calls must be - executed in a ``with`` suite:: - - @register() - class ra_certprofile(RestClient): - path = 'profile' - ... - - with api.Backend.ra_certprofile as profile_api: - # REST client is now logged in - profile_api.create_profile(...) - - """ - path = None - - @staticmethod - def _parse_dogtag_error(body): - try: - return pki.PKIException.from_json(json.loads(body)) - except Exception: - return None - - def __init__(self, api): - if api.env.in_tree: - self.sec_dir = api.env.dot_ipa + os.sep + 'alias' - self.pwd_file = self.sec_dir + os.sep + '.pwd' - else: - self.sec_dir = paths.HTTPD_ALIAS_DIR - self.pwd_file = paths.ALIAS_PWDFILE_TXT - self.noise_file = self.sec_dir + os.sep + '.noise' - self.ipa_key_size = "2048" - self.ipa_certificate_nickname = "ipaCert" - self.ca_certificate_nickname = "caCert" - self._read_password() - super(RestClient, self).__init__(api) - - # session cookie - self.override_port = None - self.cookie = None - - def _read_password(self): - try: - with open(self.pwd_file) as f: - self.password = f.readline().strip() - except IOError: - self.password = '' - - @cachedproperty - def ca_host(self): - """ - :return: host - as str - - Select our CA host. - """ - ldap2 = self.api.Backend.ldap2 - if host_has_service(api.env.ca_host, ldap2, "CA"): - return api.env.ca_host - if api.env.host != api.env.ca_host: - if host_has_service(api.env.host, ldap2, "CA"): - return api.env.host - host = select_any_master(ldap2) - if host: - return host - else: - return api.env.ca_host - - def __enter__(self): - """Log into the REST API""" - if self.cookie is not None: - return - status, resp_headers, resp_body = dogtag.https_request( - self.ca_host, self.override_port or self.env.ca_agent_port, - '/ca/rest/account/login', - self.sec_dir, self.password, self.ipa_certificate_nickname, - method='GET' - ) - cookies = ipapython.cookie.Cookie.parse(resp_headers.get('set-cookie', '')) - if status != 200 or len(cookies) == 0: - raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) - self.cookie = str(cookies[0]) - return self - - def __exit__(self, exc_type, exc_value, traceback): - """Log out of the REST API""" - dogtag.https_request( - self.ca_host, self.override_port or self.env.ca_agent_port, - '/ca/rest/account/logout', - self.sec_dir, self.password, self.ipa_certificate_nickname, - method='GET' - ) - self.cookie = None - - def _ssldo(self, method, path, headers=None, body=None, use_session=True): - """ - Perform an HTTPS request. - - ``method`` - HTTP method to use - ``path`` - Path component. This will *extend* the path defined for - the class (if any). - ``headers`` - Additional headers to include in the request. - ``body`` - Request body. - ``use_session`` - If ``True``, session cookie is added to request (client - must be logged in). - - :return: (http_status, http_headers, http_body) - as (integer, dict, str) - - """ - headers = headers or {} - - if use_session: - if self.cookie is None: - raise errors.RemoteRetrieveError( - reason=_("REST API is not logged in.")) - headers['Cookie'] = self.cookie - - resource = '/ca/rest' - if self.path is not None: - resource = os.path.join(resource, self.path) - if path is not None: - resource = os.path.join(resource, path) - - # perform main request - status, resp_headers, resp_body = dogtag.https_request( - self.ca_host, self.override_port or self.env.ca_agent_port, - resource, - self.sec_dir, self.password, self.ipa_certificate_nickname, - method=method, headers=headers, body=body - ) - if status < 200 or status >= 300: - explanation = self._parse_dogtag_error(resp_body) or '' - raise errors.HTTPRequestError( - status=status, - reason=_('Non-2xx response from CA REST API: %(status)d. %(explanation)s') - % {'status': status, 'explanation': explanation} - ) - return (status, resp_headers, resp_body) - - @register() class ra_certprofile(RestClient): """ -- 2.5.5 -------------- next part -------------- From 40e3635a448ab22fef5dda38f7dc543407b0cf41 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 26 Aug 2016 11:11:56 +1000 Subject: [PATCH 105/105] cert-request: raise CertificateOperationError if CA disabled Detect when cert-request returns HTTP 409, which indicates that the target CA is disabled - a valid scenario - and raise CertificateOperationError with a friendly message instead of HTTPRequestError. Fixes: https://fedorahosted.org/freeipa/ticket/6260 --- ipaserver/plugins/cert.py | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 6dd9f6ffcdcd9d051d50d912996fea2104d71dff..e7b0a74b5311f2bb4533fe822ad46df6eba98b35 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -618,8 +618,16 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): name_type) # Request the certificate - result = self.Backend.ra.request_certificate( - csr, profile_id, ca_id, request_type=request_type) + try: + result = self.Backend.ra.request_certificate( + csr, profile_id, ca_id, request_type=request_type) + except errors.HTTPRequestError as e: + if e.status == 409: # pylint: disable=E1101 + raise errors.CertificateOperationError( + error=_("CA '%s' is disabled") % ca) + else: + raise e + if not raw: self.obj._parse(result) result['request_id'] = int(result['request_id']) -- 2.5.5 From ftweedal at redhat.com Fri Aug 26 05:37:17 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 26 Aug 2016 15:37:17 +1000 Subject: [Freeipa-devel] [PATCH] 0106 Make host/service cert revocation aware of lightweight CAs Message-ID: <20160826053717.GP3877@dhcp-40-8.bne.redhat.com> Hi all, Attached patch fixes https://fedorahosted.org/freeipa/ticket/6221. It depends on Honza's PR #20 https://github.com/freeipa/freeipa/pull/20. Thanks, Fraser From ftweedal at redhat.com Fri Aug 26 05:42:22 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 26 Aug 2016 15:42:22 +1000 Subject: [Freeipa-devel] [PATCH] 0106 Make host/service cert revocation aware of lightweight CAs In-Reply-To: <20160826053717.GP3877@dhcp-40-8.bne.redhat.com> References: <20160826053717.GP3877@dhcp-40-8.bne.redhat.com> Message-ID: <20160826054222.GQ3877@dhcp-40-8.bne.redhat.com> On Fri, Aug 26, 2016 at 03:37:17PM +1000, Fraser Tweedale wrote: > Hi all, > > Attached patch fixes https://fedorahosted.org/freeipa/ticket/6221. > It depends on Honza's PR #20 > https://github.com/freeipa/freeipa/pull/20. > > Thanks, > Fraser > It does help to attach the patch :) -------------- next part -------------- From 35ab316731d49d503a66d8621b1812a2eb50d180 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 26 Aug 2016 15:31:13 +1000 Subject: [PATCH] Make host/service cert revocation aware of lightweight CAs Revocation of host/service certs on host/service deletion is broken when cert is issued by a lightweight (sub)CA, causing the delete operation to be aborted. Look up the issuing CA and pass it to 'cert_revoke' to fix the issue. Fixes: https://fedorahosted.org/freeipa/ticket/6221 --- ipaserver/plugins/service.py | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/ipaserver/plugins/service.py b/ipaserver/plugins/service.py index 04d1916fe989a8651bcc4d44f1914c460be1081c..ada5cd1e6f0d289332d77ec651732ba70843ff65 100644 --- a/ipaserver/plugins/service.py +++ b/ipaserver/plugins/service.py @@ -232,19 +232,38 @@ def revoke_certs(certs, logger=None): logger.info("Problem decoding certificate: %s" % e) serial = unicode(x509.get_serial_number(cert, x509.DER)) + issuer = unicode(x509.get_issuer(cert, x509.DER)) try: - result = api.Command['cert_show'](unicode(serial))['result'] + # search by serial+issuer, not full cert match + results = api.Command['cert_find']( + min_serial_number=serial, + max_serial_number=serial, + issuer=issuer + )['result'] + if len(results) == 0: + # Dogtag doesn't know about the cert therefore + # we cannot revoke it. Perhaps it was issued by + # a 3rd-party CA. + continue + result = results[0] except errors.CertificateOperationError: continue - if 'revocation_reason' in result: + if result['status'] in {'REVOKED', 'REVOKED_EXPIRED'}: continue - if x509.normalize_certificate(result['certificate']) != cert: + if 'cacn' not in result: + # cert is known to Dogtag, but CA appears to have been + # deleted. We cannot revoke this cert via IPA anymore. + # We could go directly to Dogtag to revoke it, but the + # issuer's cert should have been revoked so never mind. continue try: - api.Command['cert_revoke'](unicode(serial), - revocation_reason=4) + api.Command['cert_revoke']( + serial, + cacn=result['cacn'], + revocation_reason=4, + ) except errors.NotImplementedError: # some CA's might not implement revoke pass -- 2.5.5 From freeipa-github-notification at redhat.com Fri Aug 26 06:13:47 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Fri, 26 Aug 2016 08:13:47 +0200 Subject: [Freeipa-devel] [freeipa PR#24] [master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name (opened) In-Reply-To: References: Message-ID: mirielka's pull request #24: "[master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name" was opened PR body: """ When running ipa-adtrust-install, a netbios-name option must be specified. Currently if an invalid netbios name in form of empty string is specified, the installation proceeds, but changes the invalid value to a netbios name determined from domain name without any notification. Fixing this so that any attempt to supply empty string as netbios name fails with error in case of unattended installation, or to request input of valid netbios name from command line during normal installation. https://fedorahosted.org/freeipa/ticket/6120 **Note - newly intended behavirour of ipa-adtrust-install:** - unattended installation with --netbios-name="" fails - unattended installation without --netbios-name specification proceeds and uses default value derived from domain name - normal installation in both cases requests inserting of valid netbios name """ See the full pull-request at https://github.com/freeipa/freeipa/pull/24 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/24/head:pr24 git checkout pr24 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-24.patch URL: From freeipa-github-notification at redhat.com Fri Aug 26 06:14:01 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Fri, 26 Aug 2016 08:14:01 +0200 Subject: [Freeipa-devel] [freeipa PR#24] [master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name (edited) In-Reply-To: References: Message-ID: mirielka's pull request #24: "[master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name" was edited See the full pull-request at https://github.com/freeipa/freeipa/pull/24 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/24/head:pr24 git checkout pr24 From jcholast at redhat.com Fri Aug 26 07:10:19 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Aug 2016 09:10:19 +0200 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: <20160823094657.GE3877@dhcp-40-8.bne.redhat.com> References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> <43675032-5d07-262a-b735-d1938e8feb98@redhat.com> <7107b69c-d0d4-612a-1191-cc29f1ec97c2@redhat.com> <20160815071516.GL23927@dhcp-40-8.bne.redhat.com> <20160819111122.GP3877@dhcp-40-8.bne.redhat.com> <20160823094657.GE3877@dhcp-40-8.bne.redhat.com> Message-ID: On 23.8.2016 11:46, Fraser Tweedale wrote: > Thanks for review; rebased and updated patch attached. Only 0090 > has substantive changes. > > Cheers, > Fraser > > On Mon, Aug 22, 2016 at 09:22:08AM +0200, Jan Cholasta wrote: >> On 19.8.2016 13:11, Fraser Tweedale wrote: >>> Bump for review. >>> >>> On Mon, Aug 15, 2016 at 05:15:16PM +1000, Fraser Tweedale wrote: >>>> Thanks for reviews. Rebased and updated patches attached (and one >>>> new patch). No substantive changes to 92..94. Patch order is: >>>> >>>> 92-2, 93-2, 94-2, 98, 90-3 >>>> >>>> Other comments inline. >>>> >>>> Thanks, >>>> Fraser >>>> >>>> On Fri, Aug 12, 2016 at 11:33:28AM +0200, Jan Cholasta wrote: >>>>> Patch 0092: ACK >>>>> >>>>> Patch 0093: ACK >>>>> >>>>> Patch 0094: ACK >> >> Please fix this PEP8 issue before pushing: >> >> ./ipaserver/plugins/cert.py:597:17: W503 line break before binary operator >> >> >> Patch 0098: ACK >> >>>>> >>>>> Patch 0090: >>>>> >>>>> 1) Generic otherNames (san_other) do not work correctly. The OID is not >>>>> included in the value and names with complex type other than >>>>> KerberosPrincipal are not parsed correctly. The value should include the OID >>>>> and DER blob of the name. >>>>> >>>> Updated to use "OID:b64(DER)" as the attribute value. >> >> OK. >> >>>> >>>>> 2) With --all, san_other should be included in the result for all >>>>> otherNames, even the known ones, to provide (limited) forward compatibility. >>>>> >>>> Done; when --all given, known otherName kinds are included in >>>> 'san_other' attribute in addition to their own attribute. >> >> OK. >> >>>> >>>>> 3) Do we have to support *all* the name types? I mean we could, for the sake >>>>> of completeness, but it might be easier to just keep the few ones we >>>>> actually care about (email, DNS name, principal name, UPN and directory name >>>>> in your patch 0095). >>>>> >>>> Yeah, why not support them all? See also Petr's comments in other >>>> branch of thread. >> >> Works for me, but see Luk??'s reply, I think he has a point. Maybe we can >> make a compromise and show only supported name types by default and >> everything with --all? >> > Now only showing DNSName, RFC822Name, DirectoryName, UPN and > KRBPrincipalName unless --all is given. > >>>> >>>>> 4) >>>>> >>>>> + obj.setdefault(attr_name, []).append(unicode(name)) >>>>> >>>>> The value should not (always) be unicode, but of the type declared by the >>>>> param (unicode or ipapython.kerberos.Principal or >>>>> ipapython.dnsutil.DNSName). >>>>> >>>> I now pass the value to the constructor of whatever type the >>>> parameter uses: >>>> >>>> attr_value = self.params[attr_name].type(name_formatted) >>>> obj.setdefault(attr_name, []).append(attr_value) >> >> OK. >> >> >> 5) san_directoryname should be a DNParam rather than Str. >> > Fixed, thanks. > >> >> 6) Could we use "Subject " instead of "Subject Alternative Name >> ()" for labels? Or something else which is shorter and has the >> name type more "visible" than the current form. >> > No worries. > >> >> 7) The patch needs a rebase. Thanks, ACK, but I have a couple additional nitpicks: 8) I think we should move the san_* param definitions right after subject param definition, so that they are visually close in CLI output. 9) san_directoryname should be added to default_attrs in patch 95, not here. I took the liberty of fixing these myself. Pushed to master: 48aaf2bbf5df6dcedaa466753c8fafb478cb31b2 Honza -- Jan Cholasta From jcholast at redhat.com Fri Aug 26 08:28:58 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Aug 2016 10:28:58 +0200 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <20160819111156.GQ3877@dhcp-40-8.bne.redhat.com> References: <20160808043424.GG11092@dhcp-40-8.bne.redhat.com> <0d50ac96-f449-c643-952d-c8089ef19b02@redhat.com> <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> <885c4c72-6e8a-4220-b25e-f577612368d2@redhat.com> <20160809144716.GA23927@dhcp-40-8.bne.redhat.com> <20160816052401.GR23927@dhcp-40-8.bne.redhat.com> <7ad5a28f-9670-b76a-f100-1a6681ac52e5@redhat.com> <20160816140939.GV23927@dhcp-40-8.bne.redhat.com> <20160819111156.GQ3877@dhcp-40-8.bne.redhat.com> Message-ID: On 19.8.2016 13:11, Fraser Tweedale wrote: > Bump for review. > > On Wed, Aug 17, 2016 at 12:09:39AM +1000, Fraser Tweedale wrote: >> On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: >>> On 16.8.2016 07:24, Fraser Tweedale wrote: >>>> On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: >>>>> On 9.8.2016 16:47, Fraser Tweedale wrote: >>>>>> On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: >>>>>>> On 8.8.2016 09:06, Fraser Tweedale wrote: >>>>>>>> On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 8.8.2016 06:34, Fraser Tweedale wrote: >>>>>>>>>> Please review the attached patch with adds --certificate-out and >>>>>>>>>> --certificate-chain-out options to `ca-show' command. >>>>>>>>>> >>>>>>>>>> Note that --certificate-chain-out currently writes a bogus file due >>>>>>>>>> to a bug in Dogtag that will be fixed in this week's build. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6178 >>>>>>>>> >>>>>>>>> 1) The client-side *-out options should be defined on the client side, not >>>>>>>>> on the server side. >>>>>>>>> >>>>>>>> Will option defined on client side be propagated to, and observable >>>>>>>> in the ipaserver plugin? The ipaserver plugin needs to observe that >>>>>>>> *-out has been requested and executes additional command(s) on that >>>>>>>> basis. >>>>>>> >>>>>>> Is there a reason not to *always* return the certs? >>>>>>> >>>>>> We hit Dogtag to retrieve them. >>>>> >>>>> I don't think that's an issue in a -show command. >>>>> >>>> cert_show is invoked by other commands (cert_find*, cert_show, >>>> cert_request, cert_status, ca_del) but these all hit Dogtag anyway >>>> so I suppose that's fine. I'll return the cert *and* the chain in >>>> separate attributes, unconditionally. >>>> >>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 2) I don't think there should be additional information included in summary >>>>>>>>> (and it definitely should not be multi-line). I would rather inform the user >>>>>>>>> via an error message when unable to write the files. >>>>>>>>> >>>>>>>> I was just following the pattern of other commands that write certs, >>>>>>>> profile config, etc. Apart from consistency with other commands I >>>>>>>> agree that there is no need to have it. So I will remove it. >>>>>>>> >>>>>>>>> If you think there is an actual value in informing the user about >>>>>>>>> successfully writing the files, please use ipalib.messages for the job. >>>>>>>>> >>>>>>>>> >>>>>>>>> 3) IMO a better format for the certificate chain than PKCS#7 would be >>>>>>>>> concatenated PEM, as that's the most commonly used format in IPA (in >>>>>>>>> installers, there are no cert chains in API commands ATM). >>>>>>>>> >>>>>>>> Sure, but the main use case isn't IPA. Other apps require PKCS #7 >>>>>>>> or concatenated PEMs, but sometimes they must be concatenated >>>>>>>> forward, and othertimes backwards. There is no one size fits all. >>>>>>> >>>>>>> True, which is exactly why I think we should at least be self-consistent and >>>>>>> use concatenated PEM (and multi-value DER over the wire). >>>>>>> >>>>>> Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept >>>>>> header). >>>>>> >>>>>> If we want list-of-PEMs between server and client we have to convert >>>>>> on the server. Do we have a good way of doing this without exec'ing >>>>>> `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' >>>>>> to do the conversion on the server? python-nss does not have PKCS7 >>>>>> functions and I am not keen on adding a pyasn1 PKCS7 parser just for >>>>>> the sake of pushing bits as list-of-PEMs. >>>>> >>>>> I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other. >>>>> For example, if we added a call to retrieve external CA chain using certs >>>>> from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to >>>>> PKCS#7 if it was our cert chain format of choice. >>>>> >>>>> What we can avoid though is executing "openssl pkcs7" to do the conversion - >>>>> we can use an approach similar to our DNSSEC code and use python-cffi to >>>>> call libcrypto's PKCS#7 conversion routines instead. >>>>> >>>> I had a look at the OpenSSL API for parsing PKCS #7; now I prefer to >>>> exec `openssl' to do the job :) >>>> >>>> I will transmit DER-encoded PKCS #7 object on the wire; we cannot >>>> used multi-valued DER attribute because order is important. Client >>>> will convert to PEMs. >>> >>> Well, my point was not to send PKCS#7 over the wire, so that clients >>> (including 3rd party clients) do not have to convert from PKCS#7 themselves. >>> >>> In fact we can use multi-valued DER - whatever you send over the wire from >>> the server will be received in the exact same order by the client. Even if >>> it wasn't, you can easily restore the order by matching issuer and subject >>> names of the certificates. >>> >>>> >>>> Should have new patch on list this afternoon. >>>> >>>> Thanks, >>>> Fraser >>>> >>>>>> >>>>>> FWIW, man pages and code suggest that PKCS #7 is accepted in >>>>>> installer, etc. >>>>> >>>>> True, but that's a relatively new feature (since 4.1) and the installer >>>>> internally executes "openssl pkcs7" to convert PKCS #7 to list of certs :-) >>>>> >>>>>> >>>>>>>> We can add an option to control the format later, but for now, >>>>>>>> Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst >>>>>>>> case is an admin has to invoke `openssl pkcs7' and concat the certs >>>>>>>> themselves. >>>>>>> >>>>>>> AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, >>>>>>> so I'm afraid the worst case would happen virtually always. >>>>>>> >>>>>> If you're OK with invoking OpenSSL on the client to convert PKCS #7 >>>>>> to list-of-PEMs (similar to what is done in >>>>>> ipapython.certdb.NSSDatabase) then we can have the client perform >>>>>> the conversion. >>>>> >>>>> See above. >>>>> >>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 4) Over the wire, the certs should be DER-formatted, as that's the most >>>>>>>>> common wire format in other API commands. >>>>>>>>> >>>>>>>> OK. >>>>>>>> >>>>>>>>> >>>>>>>>> 5) What is the benefit in having the CA cert and the rest of the chain >>>>>>>>> separate? For end-entity certs it makes sense to separate the cert from the >>>>>>>>> CA chain, but for CA certs, you usually want the full chain, no? >>>>>>>>> >>>>>>>> If you want to anchor trust directly at a subca (e.g. restrict VPN >>>>>>>> login to certs issued by VPN sub-CA) then you often just want the >>>>>>>> cert. The chain option does subsume it, at cost of more work for >>>>>>>> administrators with this use case. I think it makes sense to keep >>>>>>>> both options. >>>>>>> >>>>>>> Does it? From what you described above, you either want just the sub-CA >>>>>>> cert, or the full chain including the sub-CA cert, in which case it might >>>>>>> make more sense to have a single --out option and a --chain flag. >>>>>>> >>>>>> How about --certificate-out which defaults to single cert, but does >>>>>> chain (as list-of-PEMs) when --chain flag given. >>>>>> >>>>>> Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more >>>>>> `--out' options. >>>>> >>>>> +1 >>>>> >> Updated patch 0097-2 attached, and new patch 0099 which must be >> applied first. >> >> I have implemented the suggested changes, except for cffi (I execute >> `openssl pkcs7' instead). I don't like it, but OK. Another alternative would be to use pyasn1. >> >> There are two new output attributes on the wire, 'certificate' >> (single-value DER X.509), and 'certificate_chain' (ordered >> multi-value DER X.509). They are always returned. The first cert >> in the chain is always the same as 'certificate'; obviously this is >> redunant but I have left it this way because I think usage is >> clearer. I don't have a strong feeling about this one way or the other, but the same scheme should be used for cert-show in the future. Does it make sense to do it this way for cert-show? I'm not sure about always returning the chain in cert-show. Now that we have a --chain flag rather than two out options, maybe we should go back to returning the chain only if --chain is specified. What do you think? Patch 0099: 1) Please fix this: $ git show -U0 | pep8 --diff ./ipalib/x509.py:59:80: E501 line too long (93 > 79 characters) Patch 0097: 1) `certificate` and `certificate_chain` are actually attributes of the ca object, so they should be defined in ca.takes_params rather than ca_show.has_output_params. 2) Please fix these: $ git show -U0 | pep8 --diff ./ipaclient/plugins/ca.py:21:9: E124 closing bracket does not match visual indentation ./ipaclient/plugins/ca.py:23:13: E128 continuation line under-indented for visual indent ./ipaclient/plugins/ca.py:24:13: E128 continuation line under-indented for visual indent ./ipaclient/plugins/ca.py:25:13: E128 continuation line under-indented for visual indent ./ipaclient/plugins/ca.py:26:9: E124 closing bracket does not match visual indentation ./ipaclient/plugins/ca.py:38:13: E731 do not assign a lambda expression, use a def Honza -- Jan Cholasta From jcholast at redhat.com Fri Aug 26 08:41:37 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Aug 2016 10:41:37 +0200 Subject: [Freeipa-devel] [PATCH] 0095 cert-request: allow directoryName in SAN extension In-Reply-To: <20160722051807.GJ10771@dhcp-40-8.bne.redhat.com> References: <20160722051807.GJ10771@dhcp-40-8.bne.redhat.com> Message-ID: Hi, On 22.7.2016 07:18, Fraser Tweedale wrote: > While I was poking around SAN-processing code, I decided to > implement a small enhancement: allowing the subject principal's DN > to appear in SAN. > > https://fedorahosted.org/freeipa/ticket/6112 > > Patch depends on my other patches 0090, 0092, 0093, 0094. I don't think this is how DN SANs are supposed to be handled. For example, see this bit about DN name constraints in RFC 5280 section 4.2.1.10: Restrictions of the form directoryName MUST be applied to the subject field in the certificate (when the certificate includes a non-empty subject field) and to any names of type directoryName in the subjectAltName extension. It would appear to me that DN SANs only provide additional values to the subject name of the certificate and thus should be treated the same way as the subject name. We don't impose any restrictions on subject names with regard to DN of the subject LDAP entry, so I think we should not do it for DN SANs as well. Or, alternatively, we should do it for both. Honza -- Jan Cholasta From freeipa-github-notification at redhat.com Fri Aug 26 08:47:56 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Fri, 26 Aug 2016 10:47:56 +0200 Subject: [Freeipa-devel] [freeipa PR#20] cert: include CA name in cert command output (synchronize) In-Reply-To: References: Message-ID: jcholast's pull request #20: "cert: include CA name in cert command output" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/20 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/20/head:pr20 git checkout pr20 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-20.patch URL: From freeipa-github-notification at redhat.com Fri Aug 26 09:21:13 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Fri, 26 Aug 2016 11:21:13 +0200 Subject: [Freeipa-devel] [freeipa PR#20] cert: include CA name in cert command output (synchronize) In-Reply-To: References: Message-ID: jcholast's pull request #20: "cert: include CA name in cert command output" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/20 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/20/head:pr20 git checkout pr20 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-20.patch URL: From jcholast at redhat.com Fri Aug 26 09:43:27 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Aug 2016 11:43:27 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: References: Message-ID: Hi, On 11.8.2016 12:34, Stanislav Laznicka wrote: > Hello, > > I updated the design of the Time-Based HBAC Policies according to the > discussion we led here earlier. Please check the design page > http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest > changes are in the Implementation and Feature Management sections. I > also added a short How to Use section. 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> ipaMemberTimeRule 2) Source hosts are deprecated and thus should be removed from ipaHBACRuleV2. 3) Since time rules are defined by memberTimeRule, accessTime should be removed from ipaHBACRuleV2. 4) The CLI sections needs more work, especially for non-standard commands like timerule-test. > > On the link below is a PROTOTYPE-patched FreeIPA that covers most of the > CLI functionality (except for the creation of iCalendar strings from > options) for better illustration of the design. > > https://github.com/stlaz/freeipa/tree/timerules_2 > > I will add FreeIPA people that recently had some say about this to CC so > that we can get the discussion flowing. Honza -- Jan Cholasta From freeipa-github-notification at redhat.com Fri Aug 26 09:48:08 2016 From: freeipa-github-notification at redhat.com (Akasurde) Date: Fri, 26 Aug 2016 11:48:08 +0200 Subject: [Freeipa-devel] [freeipa PR#25] Added install check before executing ipa-* command (opened) In-Reply-To: References: Message-ID: Akasurde's pull request #25: "Added install check before executing ipa-* command" was opened PR body: """ Fixes: https://fedorahosted.org/freeipa/ticket/6261 Signed-off-by: Abhijeet Kasurde """ See the full pull-request at https://github.com/freeipa/freeipa/pull/25 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/25/head:pr25 git checkout pr25 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-25.patch URL: From mbasti at redhat.com Fri Aug 26 09:55:53 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 26 Aug 2016 11:55:53 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: References: Message-ID: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> On 26.08.2016 11:43, Jan Cholasta wrote: > Hi, > > On 11.8.2016 12:34, Stanislav Laznicka wrote: >> Hello, >> >> I updated the design of the Time-Based HBAC Policies according to the >> discussion we led here earlier. Please check the design page >> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest >> changes are in the Implementation and Feature Management sections. I >> also added a short How to Use section. > > 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> > ipaMemberTimeRule > > > 2) Source hosts are deprecated and thus should be removed from > ipaHBACRuleV2. > > > 3) Since time rules are defined by memberTimeRule, accessTime should > be removed from ipaHBACRuleV2. ad 2) 3) Because backward compatibility, ipaHBACRuleV2 must contain all attributes from ipaHBACRule as MAY With current approach, when timerule is added to HBAC, we just change objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all attributes that was defined in older HBAC. Removing any attrs from ipaHBACRuleV2 can cause schema violation. I'm not sure if want to handle this in code (removing deprecated attributes from HBAC entry when timerule is added) I realized that AccessTime is MUST for 'ipahbacrule', so when timerule ('ipahbacrulev2') is removed and somebody deleted accesstime we have to add it back. > > > 4) The CLI sections needs more work, especially for non-standard > commands like timerule-test. > >> >> On the link below is a PROTOTYPE-patched FreeIPA that covers most of the >> CLI functionality (except for the creation of iCalendar strings from >> options) for better illustration of the design. >> >> https://github.com/stlaz/freeipa/tree/timerules_2 >> >> I will add FreeIPA people that recently had some say about this to CC so >> that we can get the discussion flowing. > > Honza > From jcholast at redhat.com Fri Aug 26 10:13:33 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Aug 2016 12:13:33 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> Message-ID: <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> On 26.8.2016 11:55, Martin Basti wrote: > > > On 26.08.2016 11:43, Jan Cholasta wrote: >> Hi, >> >> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>> Hello, >>> >>> I updated the design of the Time-Based HBAC Policies according to the >>> discussion we led here earlier. Please check the design page >>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest >>> changes are in the Implementation and Feature Management sections. I >>> also added a short How to Use section. >> >> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> >> ipaMemberTimeRule >> >> >> 2) Source hosts are deprecated and thus should be removed from >> ipaHBACRuleV2. >> >> >> 3) Since time rules are defined by memberTimeRule, accessTime should >> be removed from ipaHBACRuleV2. > > ad 2) 3) > > Because backward compatibility, ipaHBACRuleV2 must contain all > attributes from ipaHBACRule as MAY Not true. > > With current approach, when timerule is added to HBAC, we just change > objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all > attributes that was defined in older HBAC. Removing any attrs from > ipaHBACRuleV2 can cause schema violation. Which is perfectly fine. > > > I'm not sure if want to handle this in code (removing deprecated > attributes from HBAC entry when timerule is added) We don't have to do anything. If any of the deprecated attributes are present when you change the object class (which they shouldn't anyway), you'll get schema violation, otherwise it will work just fine. > > I realized that AccessTime is MUST for 'ipahbacrule', so when timerule > ('ipahbacrulev2') is removed and somebody deleted accesstime we have to > add it back. It is MAY. The only MUST attribute is accessRuleType, but that is deprecated as well and should be removed from ipaHBACRuleV2. We only support allow rules, so when timerule is removed, that's the value you set accessRuleType to. > > > >> >> >> 4) The CLI sections needs more work, especially for non-standard >> commands like timerule-test. >> >>> >>> On the link below is a PROTOTYPE-patched FreeIPA that covers most of the >>> CLI functionality (except for the creation of iCalendar strings from >>> options) for better illustration of the design. >>> >>> https://github.com/stlaz/freeipa/tree/timerules_2 >>> >>> I will add FreeIPA people that recently had some say about this to CC so >>> that we can get the discussion flowing. >> >> Honza >> > -- Jan Cholasta From abokovoy at redhat.com Fri Aug 26 10:20:21 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 26 Aug 2016 13:20:21 +0300 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> Message-ID: <20160826102021.h64hfjrvky4bitrw@redhat.com> On Fri, 26 Aug 2016, Jan Cholasta wrote: >On 26.8.2016 11:55, Martin Basti wrote: >> >> >>On 26.08.2016 11:43, Jan Cholasta wrote: >>>Hi, >>> >>>On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>>Hello, >>>> >>>>I updated the design of the Time-Based HBAC Policies according to the >>>>discussion we led here earlier. Please check the design page >>>>http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest >>>>changes are in the Implementation and Feature Management sections. I >>>>also added a short How to Use section. >>> >>>1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> >>>ipaMemberTimeRule >>> >>> >>>2) Source hosts are deprecated and thus should be removed from >>>ipaHBACRuleV2. >>> >>> >>>3) Since time rules are defined by memberTimeRule, accessTime should >>>be removed from ipaHBACRuleV2. >> >>ad 2) 3) >> >>Because backward compatibility, ipaHBACRuleV2 must contain all >>attributes from ipaHBACRule as MAY > >Not true. > >> >>With current approach, when timerule is added to HBAC, we just change >>objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >>attributes that was defined in older HBAC. Removing any attrs from >>ipaHBACRuleV2 can cause schema violation. > >Which is perfectly fine. > >> >> >>I'm not sure if want to handle this in code (removing deprecated >>attributes from HBAC entry when timerule is added) > >We don't have to do anything. If any of the deprecated attributes are >present when you change the object class (which they shouldn't >anyway), you'll get schema violation, otherwise it will work just >fine. > >> >>I realized that AccessTime is MUST for 'ipahbacrule', so when timerule >>('ipahbacrulev2') is removed and somebody deleted accesstime we have to >>add it back. > >It is MAY. The only MUST attribute is accessRuleType, but that is >deprecated as well and should be removed from ipaHBACRuleV2. We only >support allow rules, so when timerule is removed, that's the value you >set accessRuleType to. SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter. Changing to ipaHBACRuleV2 means these rules will not be found by older SSSD versions and therefore people will experience problems with older clients not being able to use new rules even if they would lack time component. -- / Alexander Bokovoy From mbasti at redhat.com Fri Aug 26 10:21:04 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 26 Aug 2016 12:21:04 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> Message-ID: <81e4a5ab-863c-8373-82e6-8e00ff199b08@redhat.com> On 26.08.2016 12:13, Jan Cholasta wrote: > On 26.8.2016 11:55, Martin Basti wrote: >> >> >> On 26.08.2016 11:43, Jan Cholasta wrote: >>> Hi, >>> >>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>> Hello, >>>> >>>> I updated the design of the Time-Based HBAC Policies according to the >>>> discussion we led here earlier. Please check the design page >>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The >>>> biggest >>>> changes are in the Implementation and Feature Management sections. I >>>> also added a short How to Use section. >>> >>> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> >>> ipaMemberTimeRule >>> >>> >>> 2) Source hosts are deprecated and thus should be removed from >>> ipaHBACRuleV2. >>> >>> >>> 3) Since time rules are defined by memberTimeRule, accessTime should >>> be removed from ipaHBACRuleV2. >> >> ad 2) 3) >> >> Because backward compatibility, ipaHBACRuleV2 must contain all >> attributes from ipaHBACRule as MAY > > Not true. > >> >> With current approach, when timerule is added to HBAC, we just change >> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >> attributes that was defined in older HBAC. Removing any attrs from >> ipaHBACRuleV2 can cause schema violation. > > Which is perfectly fine. > >> >> >> I'm not sure if want to handle this in code (removing deprecated >> attributes from HBAC entry when timerule is added) > > We don't have to do anything. If any of the deprecated attributes are > present when you change the object class (which they shouldn't > anyway), you'll get schema violation, otherwise it will work just fine. I'm not sure if this is user friendly. > >> >> I realized that AccessTime is MUST for 'ipahbacrule', so when timerule >> ('ipahbacrulev2') is removed and somebody deleted accesstime we have to >> add it back. > > It is MAY. The only MUST attribute is accessRuleType, but that is > deprecated as well and should be removed from ipaHBACRuleV2. We only > support allow rules, so when timerule is removed, that's the value you > set accessRuleType to. > Right, sorry. Martin^2 >> >> >> >>> >>> >>> 4) The CLI sections needs more work, especially for non-standard >>> commands like timerule-test. >>> >>>> >>>> On the link below is a PROTOTYPE-patched FreeIPA that covers most >>>> of the >>>> CLI functionality (except for the creation of iCalendar strings from >>>> options) for better illustration of the design. >>>> >>>> https://github.com/stlaz/freeipa/tree/timerules_2 >>>> >>>> I will add FreeIPA people that recently had some say about this to >>>> CC so >>>> that we can get the discussion flowing. >>> >>> Honza >>> >> > > From jcholast at redhat.com Fri Aug 26 10:27:36 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Aug 2016 12:27:36 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <81e4a5ab-863c-8373-82e6-8e00ff199b08@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <81e4a5ab-863c-8373-82e6-8e00ff199b08@redhat.com> Message-ID: <8362164e-9f33-54d3-080b-7dd7bc69bd41@redhat.com> On 26.8.2016 12:21, Martin Basti wrote: > > > On 26.08.2016 12:13, Jan Cholasta wrote: >> On 26.8.2016 11:55, Martin Basti wrote: >>> >>> >>> On 26.08.2016 11:43, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>>> Hello, >>>>> >>>>> I updated the design of the Time-Based HBAC Policies according to the >>>>> discussion we led here earlier. Please check the design page >>>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The >>>>> biggest >>>>> changes are in the Implementation and Feature Management sections. I >>>>> also added a short How to Use section. >>>> >>>> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> >>>> ipaMemberTimeRule >>>> >>>> >>>> 2) Source hosts are deprecated and thus should be removed from >>>> ipaHBACRuleV2. >>>> >>>> >>>> 3) Since time rules are defined by memberTimeRule, accessTime should >>>> be removed from ipaHBACRuleV2. >>> >>> ad 2) 3) >>> >>> Because backward compatibility, ipaHBACRuleV2 must contain all >>> attributes from ipaHBACRule as MAY >> >> Not true. >> >>> >>> With current approach, when timerule is added to HBAC, we just change >>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >>> attributes that was defined in older HBAC. Removing any attrs from >>> ipaHBACRuleV2 can cause schema violation. >> >> Which is perfectly fine. >> >>> >>> >>> I'm not sure if want to handle this in code (removing deprecated >>> attributes from HBAC entry when timerule is added) >> >> We don't have to do anything. If any of the deprecated attributes are >> present when you change the object class (which they shouldn't >> anyway), you'll get schema violation, otherwise it will work just fine. > > I'm not sure if this is user friendly. You can obviously catch the schema violation and provided a meaningful error instead. > >> >>> >>> I realized that AccessTime is MUST for 'ipahbacrule', so when timerule >>> ('ipahbacrulev2') is removed and somebody deleted accesstime we have to >>> add it back. >> >> It is MAY. The only MUST attribute is accessRuleType, but that is >> deprecated as well and should be removed from ipaHBACRuleV2. We only >> support allow rules, so when timerule is removed, that's the value you >> set accessRuleType to. >> > Right, sorry. > Martin^2 > >>> >>> >>> >>>> >>>> >>>> 4) The CLI sections needs more work, especially for non-standard >>>> commands like timerule-test. >>>> >>>>> >>>>> On the link below is a PROTOTYPE-patched FreeIPA that covers most >>>>> of the >>>>> CLI functionality (except for the creation of iCalendar strings from >>>>> options) for better illustration of the design. >>>>> >>>>> https://github.com/stlaz/freeipa/tree/timerules_2 >>>>> >>>>> I will add FreeIPA people that recently had some say about this to >>>>> CC so >>>>> that we can get the discussion flowing. >>>> >>>> Honza >>>> >>> >> >> > -- Jan Cholasta From mbasti at redhat.com Fri Aug 26 10:23:30 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 26 Aug 2016 12:23:30 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <20160826102021.h64hfjrvky4bitrw@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> Message-ID: On 26.08.2016 12:20, Alexander Bokovoy wrote: > On Fri, 26 Aug 2016, Jan Cholasta wrote: >> On 26.8.2016 11:55, Martin Basti wrote: >>> >>> >>> On 26.08.2016 11:43, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>>> Hello, >>>>> >>>>> I updated the design of the Time-Based HBAC Policies according to the >>>>> discussion we led here earlier. Please check the design page >>>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The >>>>> biggest >>>>> changes are in the Implementation and Feature Management sections. I >>>>> also added a short How to Use section. >>>> >>>> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> >>>> ipaMemberTimeRule >>>> >>>> >>>> 2) Source hosts are deprecated and thus should be removed from >>>> ipaHBACRuleV2. >>>> >>>> >>>> 3) Since time rules are defined by memberTimeRule, accessTime should >>>> be removed from ipaHBACRuleV2. >>> >>> ad 2) 3) >>> >>> Because backward compatibility, ipaHBACRuleV2 must contain all >>> attributes from ipaHBACRule as MAY >> >> Not true. >> >>> >>> With current approach, when timerule is added to HBAC, we just change >>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >>> attributes that was defined in older HBAC. Removing any attrs from >>> ipaHBACRuleV2 can cause schema violation. >> >> Which is perfectly fine. >> >>> >>> >>> I'm not sure if want to handle this in code (removing deprecated >>> attributes from HBAC entry when timerule is added) >> >> We don't have to do anything. If any of the deprecated attributes are >> present when you change the object class (which they shouldn't >> anyway), you'll get schema violation, otherwise it will work just fine. >> >>> >>> I realized that AccessTime is MUST for 'ipahbacrule', so when timerule >>> ('ipahbacrulev2') is removed and somebody deleted accesstime we have to >>> add it back. >> >> It is MAY. The only MUST attribute is accessRuleType, but that is >> deprecated as well and should be removed from ipaHBACRuleV2. We only >> support allow rules, so when timerule is removed, that's the value >> you set accessRuleType to. > > SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter. > Changing to ipaHBACRuleV2 means these rules will not be found by older > SSSD versions and therefore people will experience problems with older > clients not being able to use new rules even if they would lack time > component. > Older client do not support timerules, so they should not search for them. HBAC without timerules will be still have 'ipaHBACRule' objectclass and will work with old clients. Only HBAC with timerules will have assigned 'ipaHBACRuleV2' Martin^2 From pvoborni at redhat.com Fri Aug 26 10:37:09 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 26 Aug 2016 12:37:09 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> Message-ID: <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> On 08/26/2016 12:23 PM, Martin Basti wrote: > > > On 26.08.2016 12:20, Alexander Bokovoy wrote: >> On Fri, 26 Aug 2016, Jan Cholasta wrote: >>> On 26.8.2016 11:55, Martin Basti wrote: >>>> >>>> >>>> On 26.08.2016 11:43, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>>>> Hello, >>>>>> >>>>>> I updated the design of the Time-Based HBAC Policies according to the >>>>>> discussion we led here earlier. Please check the design page >>>>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The >>>>>> biggest >>>>>> changes are in the Implementation and Feature Management sections. I >>>>>> also added a short How to Use section. >>>>> >>>>> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> >>>>> ipaMemberTimeRule >>>>> >>>>> >>>>> 2) Source hosts are deprecated and thus should be removed from >>>>> ipaHBACRuleV2. >>>>> >>>>> >>>>> 3) Since time rules are defined by memberTimeRule, accessTime should >>>>> be removed from ipaHBACRuleV2. >>>> >>>> ad 2) 3) >>>> >>>> Because backward compatibility, ipaHBACRuleV2 must contain all >>>> attributes from ipaHBACRule as MAY >>> >>> Not true. >>> >>>> >>>> With current approach, when timerule is added to HBAC, we just change >>>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >>>> attributes that was defined in older HBAC. Removing any attrs from >>>> ipaHBACRuleV2 can cause schema violation. >>> >>> Which is perfectly fine. >>> >>>> >>>> >>>> I'm not sure if want to handle this in code (removing deprecated >>>> attributes from HBAC entry when timerule is added) >>> >>> We don't have to do anything. If any of the deprecated attributes are >>> present when you change the object class (which they shouldn't >>> anyway), you'll get schema violation, otherwise it will work just fine. >>> >>>> >>>> I realized that AccessTime is MUST for 'ipahbacrule', so when timerule >>>> ('ipahbacrulev2') is removed and somebody deleted accesstime we have to >>>> add it back. >>> >>> It is MAY. The only MUST attribute is accessRuleType, but that is >>> deprecated as well and should be removed from ipaHBACRuleV2. We only >>> support allow rules, so when timerule is removed, that's the value >>> you set accessRuleType to. >> >> SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter. >> Changing to ipaHBACRuleV2 means these rules will not be found by older >> SSSD versions and therefore people will experience problems with older >> clients not being able to use new rules even if they would lack time >> component. >> > > Older client do not support timerules, so they should not search for > them. HBAC without timerules will be still have 'ipaHBACRule' > objectclass and will work with old clients. Only HBAC with timerules > will have assigned 'ipaHBACRuleV2' > > Martin^2 I miss "why" part of "To be able to handle backward compatibility with ease, a new object called ipaHBACRulev2 is introduced. " in the design page. If the reason is the above - old client's should ignore time rules then it has to be mentioned there. Otherwise I don't see a reason to introduce a new object type instead of extending the current. 2. About API and CLI: wasn't there an idea to hide/not provide --icalfile=file.ics and --time=escaped_icalstring options in the first implementation. So that we can limit the support scope to only a subset of option(the OPTS part). If arbitrary ical is allowed since the beginning then we are asking for a lot of bugs filed. -- Petr Vobornik From mbasti at redhat.com Fri Aug 26 10:39:32 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 26 Aug 2016 12:39:32 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> Message-ID: On 26.08.2016 12:37, Petr Vobornik wrote: > On 08/26/2016 12:23 PM, Martin Basti wrote: >> >> On 26.08.2016 12:20, Alexander Bokovoy wrote: >>> On Fri, 26 Aug 2016, Jan Cholasta wrote: >>>> On 26.8.2016 11:55, Martin Basti wrote: >>>>> >>>>> On 26.08.2016 11:43, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I updated the design of the Time-Based HBAC Policies according to the >>>>>>> discussion we led here earlier. Please check the design page >>>>>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The >>>>>>> biggest >>>>>>> changes are in the Implementation and Feature Management sections. I >>>>>>> also added a short How to Use section. >>>>>> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> >>>>>> ipaMemberTimeRule >>>>>> >>>>>> >>>>>> 2) Source hosts are deprecated and thus should be removed from >>>>>> ipaHBACRuleV2. >>>>>> >>>>>> >>>>>> 3) Since time rules are defined by memberTimeRule, accessTime should >>>>>> be removed from ipaHBACRuleV2. >>>>> ad 2) 3) >>>>> >>>>> Because backward compatibility, ipaHBACRuleV2 must contain all >>>>> attributes from ipaHBACRule as MAY >>>> Not true. >>>> >>>>> With current approach, when timerule is added to HBAC, we just change >>>>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >>>>> attributes that was defined in older HBAC. Removing any attrs from >>>>> ipaHBACRuleV2 can cause schema violation. >>>> Which is perfectly fine. >>>> >>>>> >>>>> I'm not sure if want to handle this in code (removing deprecated >>>>> attributes from HBAC entry when timerule is added) >>>> We don't have to do anything. If any of the deprecated attributes are >>>> present when you change the object class (which they shouldn't >>>> anyway), you'll get schema violation, otherwise it will work just fine. >>>> >>>>> I realized that AccessTime is MUST for 'ipahbacrule', so when timerule >>>>> ('ipahbacrulev2') is removed and somebody deleted accesstime we have to >>>>> add it back. >>>> It is MAY. The only MUST attribute is accessRuleType, but that is >>>> deprecated as well and should be removed from ipaHBACRuleV2. We only >>>> support allow rules, so when timerule is removed, that's the value >>>> you set accessRuleType to. >>> SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter. >>> Changing to ipaHBACRuleV2 means these rules will not be found by older >>> SSSD versions and therefore people will experience problems with older >>> clients not being able to use new rules even if they would lack time >>> component. >>> >> Older client do not support timerules, so they should not search for >> them. HBAC without timerules will be still have 'ipaHBACRule' >> objectclass and will work with old clients. Only HBAC with timerules >> will have assigned 'ipaHBACRuleV2' >> >> Martin^2 > I miss "why" part of "To be able to handle backward compatibility with > ease, a new object called ipaHBACRulev2 is introduced. " in the design > page. If the reason is the above - old client's should ignore time rules > then it has to be mentioned there. Otherwise I don't see a reason to > introduce a new object type instead of extending the current. How do you want to enforce HBAC rule that have set time from 10 to 14 everyday? With the same objectclass old clients will allow this HBAC for all day. Isn't this CVE? > > > 2. About API and CLI: wasn't there an idea to hide/not provide > --icalfile=file.ics and --time=escaped_icalstring options in the first > implementation. So that we can limit the support scope to only a subset > of option(the OPTS part). If arbitrary ical is allowed since the > beginning then we are asking for a lot of bugs filed. > From pvoborni at redhat.com Fri Aug 26 10:42:17 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 26 Aug 2016 12:42:17 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> Message-ID: <24e95f5d-dd17-4287-47c2-9f23055eab2a@redhat.com> On 08/26/2016 12:39 PM, Martin Basti wrote: > > > On 26.08.2016 12:37, Petr Vobornik wrote: >> On 08/26/2016 12:23 PM, Martin Basti wrote: >>> >>> On 26.08.2016 12:20, Alexander Bokovoy wrote: >>>> On Fri, 26 Aug 2016, Jan Cholasta wrote: >>>>> On 26.8.2016 11:55, Martin Basti wrote: >>>>>> >>>>>> On 26.08.2016 11:43, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I updated the design of the Time-Based HBAC Policies according >>>>>>>> to the >>>>>>>> discussion we led here earlier. Please check the design page >>>>>>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The >>>>>>>> biggest >>>>>>>> changes are in the Implementation and Feature Management >>>>>>>> sections. I >>>>>>>> also added a short How to Use section. >>>>>>> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> >>>>>>> ipaMemberTimeRule >>>>>>> >>>>>>> >>>>>>> 2) Source hosts are deprecated and thus should be removed from >>>>>>> ipaHBACRuleV2. >>>>>>> >>>>>>> >>>>>>> 3) Since time rules are defined by memberTimeRule, accessTime should >>>>>>> be removed from ipaHBACRuleV2. >>>>>> ad 2) 3) >>>>>> >>>>>> Because backward compatibility, ipaHBACRuleV2 must contain all >>>>>> attributes from ipaHBACRule as MAY >>>>> Not true. >>>>> >>>>>> With current approach, when timerule is added to HBAC, we just change >>>>>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >>>>>> attributes that was defined in older HBAC. Removing any attrs from >>>>>> ipaHBACRuleV2 can cause schema violation. >>>>> Which is perfectly fine. >>>>> >>>>>> >>>>>> I'm not sure if want to handle this in code (removing deprecated >>>>>> attributes from HBAC entry when timerule is added) >>>>> We don't have to do anything. If any of the deprecated attributes are >>>>> present when you change the object class (which they shouldn't >>>>> anyway), you'll get schema violation, otherwise it will work just >>>>> fine. >>>>> >>>>>> I realized that AccessTime is MUST for 'ipahbacrule', so when >>>>>> timerule >>>>>> ('ipahbacrulev2') is removed and somebody deleted accesstime we >>>>>> have to >>>>>> add it back. >>>>> It is MAY. The only MUST attribute is accessRuleType, but that is >>>>> deprecated as well and should be removed from ipaHBACRuleV2. We only >>>>> support allow rules, so when timerule is removed, that's the value >>>>> you set accessRuleType to. >>>> SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter. >>>> Changing to ipaHBACRuleV2 means these rules will not be found by older >>>> SSSD versions and therefore people will experience problems with older >>>> clients not being able to use new rules even if they would lack time >>>> component. >>>> >>> Older client do not support timerules, so they should not search for >>> them. HBAC without timerules will be still have 'ipaHBACRule' >>> objectclass and will work with old clients. Only HBAC with timerules >>> will have assigned 'ipaHBACRuleV2' >>> >>> Martin^2 >> I miss "why" part of "To be able to handle backward compatibility with >> ease, a new object called ipaHBACRulev2 is introduced. " in the design >> page. If the reason is the above - old client's should ignore time rules >> then it has to be mentioned there. Otherwise I don't see a reason to >> introduce a new object type instead of extending the current. > > How do you want to enforce HBAC rule that have set time from 10 to 14 > everyday? With the same objectclass old clients will allow this HBAC for > all day. Isn't this CVE? My point is that the design is missing the explanation. > >> >> >> 2. About API and CLI: wasn't there an idea to hide/not provide >> --icalfile=file.ics and --time=escaped_icalstring options in the first >> implementation. So that we can limit the support scope to only a subset >> of option(the OPTS part). If arbitrary ical is allowed since the >> beginning then we are asking for a lot of bugs filed. >> > -- Petr Vobornik From slaznick at redhat.com Fri Aug 26 10:47:34 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Fri, 26 Aug 2016 12:47:34 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> Message-ID: <8758f2d8-c3ac-ccb6-acef-e72ce1b45ece@redhat.com> On 08/26/2016 12:39 PM, Martin Basti wrote: > > > On 26.08.2016 12:37, Petr Vobornik wrote: >> On 08/26/2016 12:23 PM, Martin Basti wrote: >>> >>> On 26.08.2016 12:20, Alexander Bokovoy wrote: >>>> On Fri, 26 Aug 2016, Jan Cholasta wrote: >>>>> On 26.8.2016 11:55, Martin Basti wrote: >>>>>> >>>>>> On 26.08.2016 11:43, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I updated the design of the Time-Based HBAC Policies according >>>>>>>> to the >>>>>>>> discussion we led here earlier. Please check the design page >>>>>>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The >>>>>>>> biggest >>>>>>>> changes are in the Implementation and Feature Management >>>>>>>> sections. I >>>>>>>> also added a short How to Use section. >>>>>>> 1) Please use the 'ipa' prefix for new attributes: >>>>>>> memberTimeRule -> >>>>>>> ipaMemberTimeRule >>>>>>> >>>>>>> >>>>>>> 2) Source hosts are deprecated and thus should be removed from >>>>>>> ipaHBACRuleV2. >>>>>>> >>>>>>> >>>>>>> 3) Since time rules are defined by memberTimeRule, accessTime >>>>>>> should >>>>>>> be removed from ipaHBACRuleV2. >>>>>> ad 2) 3) >>>>>> >>>>>> Because backward compatibility, ipaHBACRuleV2 must contain all >>>>>> attributes from ipaHBACRule as MAY >>>>> Not true. >>>>> >>>>>> With current approach, when timerule is added to HBAC, we just >>>>>> change >>>>>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >>>>>> attributes that was defined in older HBAC. Removing any attrs from >>>>>> ipaHBACRuleV2 can cause schema violation. >>>>> Which is perfectly fine. >>>>> >>>>>> >>>>>> I'm not sure if want to handle this in code (removing deprecated >>>>>> attributes from HBAC entry when timerule is added) >>>>> We don't have to do anything. If any of the deprecated attributes are >>>>> present when you change the object class (which they shouldn't >>>>> anyway), you'll get schema violation, otherwise it will work just >>>>> fine. >>>>> >>>>>> I realized that AccessTime is MUST for 'ipahbacrule', so when >>>>>> timerule >>>>>> ('ipahbacrulev2') is removed and somebody deleted accesstime we >>>>>> have to >>>>>> add it back. >>>>> It is MAY. The only MUST attribute is accessRuleType, but that is >>>>> deprecated as well and should be removed from ipaHBACRuleV2. We only >>>>> support allow rules, so when timerule is removed, that's the value >>>>> you set accessRuleType to. >>>> SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter. >>>> Changing to ipaHBACRuleV2 means these rules will not be found by older >>>> SSSD versions and therefore people will experience problems with older >>>> clients not being able to use new rules even if they would lack time >>>> component. >>>> >>> Older client do not support timerules, so they should not search for >>> them. HBAC without timerules will be still have 'ipaHBACRule' >>> objectclass and will work with old clients. Only HBAC with timerules >>> will have assigned 'ipaHBACRuleV2' >>> >>> Martin^2 >> I miss "why" part of "To be able to handle backward compatibility with >> ease, a new object called ipaHBACRulev2 is introduced. " in the design >> page. If the reason is the above - old client's should ignore time rules >> then it has to be mentioned there. Otherwise I don't see a reason to >> introduce a new object type instead of extending the current. > It's exactly that - I will mention it there, then. > How do you want to enforce HBAC rule that have set time from 10 to 14 > everyday? With the same objectclass old clients will allow this HBAC > for all day. Isn't this CVE? > Word. >> >> >> 2. About API and CLI: wasn't there an idea to hide/not provide >> --icalfile=file.ics and --time=escaped_icalstring options in the first >> implementation. So that we can limit the support scope to only a subset >> of option(the OPTS part). If arbitrary ical is allowed since the >> beginning then we are asking for a lot of bugs filed. >> > Why hide it if there's no real problem with it? The string/content only has to be cut down to the restrictions of one event per VCALENDAR but I do not see the problem there. From pvoborni at redhat.com Fri Aug 26 10:49:39 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 26 Aug 2016 12:49:39 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <8758f2d8-c3ac-ccb6-acef-e72ce1b45ece@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <8758f2d8-c3ac-ccb6-acef-e72ce1b45ece@redhat.com> Message-ID: On 08/26/2016 12:47 PM, Standa Laznicka wrote: > On 08/26/2016 12:39 PM, Martin Basti wrote: >> >> >> On 26.08.2016 12:37, Petr Vobornik wrote: >>> On 08/26/2016 12:23 PM, Martin Basti wrote: >>>> >>>> On 26.08.2016 12:20, Alexander Bokovoy wrote: >>>>> On Fri, 26 Aug 2016, Jan Cholasta wrote: >>>>>> On 26.8.2016 11:55, Martin Basti wrote: >>>>>>> >>>>>>> On 26.08.2016 11:43, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I updated the design of the Time-Based HBAC Policies according >>>>>>>>> to the >>>>>>>>> discussion we led here earlier. Please check the design page >>>>>>>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The >>>>>>>>> biggest >>>>>>>>> changes are in the Implementation and Feature Management >>>>>>>>> sections. I >>>>>>>>> also added a short How to Use section. >>>>>>>> 1) Please use the 'ipa' prefix for new attributes: >>>>>>>> memberTimeRule -> >>>>>>>> ipaMemberTimeRule >>>>>>>> >>>>>>>> >>>>>>>> 2) Source hosts are deprecated and thus should be removed from >>>>>>>> ipaHBACRuleV2. >>>>>>>> >>>>>>>> >>>>>>>> 3) Since time rules are defined by memberTimeRule, accessTime >>>>>>>> should >>>>>>>> be removed from ipaHBACRuleV2. >>>>>>> ad 2) 3) >>>>>>> >>>>>>> Because backward compatibility, ipaHBACRuleV2 must contain all >>>>>>> attributes from ipaHBACRule as MAY >>>>>> Not true. >>>>>> >>>>>>> With current approach, when timerule is added to HBAC, we just >>>>>>> change >>>>>>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >>>>>>> attributes that was defined in older HBAC. Removing any attrs from >>>>>>> ipaHBACRuleV2 can cause schema violation. >>>>>> Which is perfectly fine. >>>>>> >>>>>>> >>>>>>> I'm not sure if want to handle this in code (removing deprecated >>>>>>> attributes from HBAC entry when timerule is added) >>>>>> We don't have to do anything. If any of the deprecated attributes are >>>>>> present when you change the object class (which they shouldn't >>>>>> anyway), you'll get schema violation, otherwise it will work just >>>>>> fine. >>>>>> >>>>>>> I realized that AccessTime is MUST for 'ipahbacrule', so when >>>>>>> timerule >>>>>>> ('ipahbacrulev2') is removed and somebody deleted accesstime we >>>>>>> have to >>>>>>> add it back. >>>>>> It is MAY. The only MUST attribute is accessRuleType, but that is >>>>>> deprecated as well and should be removed from ipaHBACRuleV2. We only >>>>>> support allow rules, so when timerule is removed, that's the value >>>>>> you set accessRuleType to. >>>>> SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter. >>>>> Changing to ipaHBACRuleV2 means these rules will not be found by older >>>>> SSSD versions and therefore people will experience problems with older >>>>> clients not being able to use new rules even if they would lack time >>>>> component. >>>>> >>>> Older client do not support timerules, so they should not search for >>>> them. HBAC without timerules will be still have 'ipaHBACRule' >>>> objectclass and will work with old clients. Only HBAC with timerules >>>> will have assigned 'ipaHBACRuleV2' >>>> >>>> Martin^2 >>> I miss "why" part of "To be able to handle backward compatibility with >>> ease, a new object called ipaHBACRulev2 is introduced. " in the design >>> page. If the reason is the above - old client's should ignore time rules >>> then it has to be mentioned there. Otherwise I don't see a reason to >>> introduce a new object type instead of extending the current. >> > It's exactly that - I will mention it there, then. Thanks >> How do you want to enforce HBAC rule that have set time from 10 to 14 >> everyday? With the same objectclass old clients will allow this HBAC >> for all day. Isn't this CVE? >> > Word. >>> >>> >>> 2. About API and CLI: wasn't there an idea to hide/not provide >>> --icalfile=file.ics and --time=escaped_icalstring options in the first >>> implementation. So that we can limit the support scope to only a subset >>> of option(the OPTS part). If arbitrary ical is allowed since the >>> beginning then we are asking for a lot of bugs filed. >>> >> > Why hide it if there's no real problem with it? The string/content only > has to be cut down to the restrictions of one event per VCALENDAR but I > do not see the problem there. > OK then. -- Petr Vobornik From freeipa-github-notification at redhat.com Fri Aug 26 11:07:05 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 26 Aug 2016 13:07:05 +0200 Subject: [Freeipa-devel] [freeipa PR#26] Don't ignore --ignore-last-of-role for last CA (opened) In-Reply-To: References: Message-ID: stlaz's pull request #26: "Don't ignore --ignore-last-of-role for last CA" was opened PR body: """ Use a handler created for the purpose of deciding whether to raise exception or not. https://fedorahosted.org/freeipa/ticket/6259 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/26 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/26/head:pr26 git checkout pr26 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-26.patch URL: From freeipa-github-notification at redhat.com Fri Aug 26 11:10:34 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Fri, 26 Aug 2016 13:10:34 +0200 Subject: [Freeipa-devel] [freeipa PR#27] Tests: Fix integration sudo tests setup and checks (opened) In-Reply-To: References: Message-ID: mirielka's pull request #27: "Tests: Fix integration sudo tests setup and checks" was opened PR body: """ Adding 'defaults' sudorule to prevent requesting further user authentication. Adding checks that if a user should be rejected access, a proper error message is displayed. https://fedorahosted.org/freeipa/ticket/6262 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/27 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/27/head:pr27 git checkout pr27 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-27.patch URL: From freeipa-github-notification at redhat.com Fri Aug 26 11:12:42 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Fri, 26 Aug 2016 13:12:42 +0200 Subject: [Freeipa-devel] [freeipa PR#27] Tests: Fix integration sudo tests setup and checks (edited) In-Reply-To: References: Message-ID: mirielka's pull request #27: "Tests: Fix integration sudo tests setup and checks" was edited See the full pull-request at https://github.com/freeipa/freeipa/pull/27 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/27/head:pr27 git checkout pr27 From slaznick at redhat.com Fri Aug 26 11:34:26 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Fri, 26 Aug 2016 13:34:26 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <8362164e-9f33-54d3-080b-7dd7bc69bd41@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <81e4a5ab-863c-8373-82e6-8e00ff199b08@redhat.com> <8362164e-9f33-54d3-080b-7dd7bc69bd41@redhat.com> Message-ID: On 08/26/2016 12:27 PM, Jan Cholasta wrote: > On 26.8.2016 12:21, Martin Basti wrote: >> On 26.08.2016 12:13, Jan Cholasta wrote: >>> On 26.8.2016 11:55, Martin Basti wrote: >>>> On 26.08.2016 11:43, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>>>> Hello, >>>>>> >>>>>> I updated the design of the Time-Based HBAC Policies according to >>>>>> the >>>>>> discussion we led here earlier. Please check the design page >>>>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The >>>>>> biggest >>>>>> changes are in the Implementation and Feature Management sections. I >>>>>> also added a short How to Use section. >>>>> >>>>> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> >>>>> ipaMemberTimeRule >>>>> >>>>> >>>>> 2) Source hosts are deprecated and thus should be removed from >>>>> ipaHBACRuleV2. >>>>> >>>>> >>>>> 3) Since time rules are defined by memberTimeRule, accessTime should >>>>> be removed from ipaHBACRuleV2. >>>> >>>> ad 2) 3) >>>> >>>> Because backward compatibility, ipaHBACRuleV2 must contain all >>>> attributes from ipaHBACRule as MAY >>> >>> Not true. >>> >>>> >>>> With current approach, when timerule is added to HBAC, we just change >>>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >>>> attributes that was defined in older HBAC. Removing any attrs from >>>> ipaHBACRuleV2 can cause schema violation. >>> >>> Which is perfectly fine. >>> >>>> >>>> >>>> I'm not sure if want to handle this in code (removing deprecated >>>> attributes from HBAC entry when timerule is added) >>> >>> We don't have to do anything. If any of the deprecated attributes are >>> present when you change the object class (which they shouldn't >>> anyway), you'll get schema violation, otherwise it will work just fine. >> >> I'm not sure if this is user friendly. > > You can obviously catch the schema violation and provided a meaningful > error instead. > I don't really have a strong opinion here. My point was to be able to hold all the attributes of the old type rule to be able to switch back without losing anything. Then the new objectClass would obviously be only used so that the older clients don't get the new HBAC rules that have the restrictions they don't understand. On the other hand, we do not want the mess from the older rules there anyway if we want to use capabilities of the newer rule type so it might be fine. But if user wants to create a new rule from an old one they have to go through all the old attributes and manually remove their values which may be a bother for them. Also, I believe that there's code in SSSD that deals with some of these older attributes and this MIGHT cause schema violation even on SSSD side if we want to work with older HBAC rules in the same way as with the newer. >> >>> >>>> >>>> I realized that AccessTime is MUST for 'ipahbacrule', so when timerule >>>> ('ipahbacrulev2') is removed and somebody deleted accesstime we >>>> have to >>>> add it back. >>> >>> It is MAY. The only MUST attribute is accessRuleType, but that is >>> deprecated as well and should be removed from ipaHBACRuleV2. We only >>> support allow rules, so when timerule is removed, that's the value you >>> set accessRuleType to. >>> >> Right, sorry. >> Martin^2 >> >>>> >>>> >>>> >>>>> >>>>> >>>>> 4) The CLI sections needs more work, especially for non-standard >>>>> commands like timerule-test. >>>>> I definitely plan to look into the *test commands a bit more, I only drafted it quick yesterday. >>>>>> >>>>>> On the link below is a PROTOTYPE-patched FreeIPA that covers most >>>>>> of the >>>>>> CLI functionality (except for the creation of iCalendar strings from >>>>>> options) for better illustration of the design. >>>>>> >>>>>> https://github.com/stlaz/freeipa/tree/timerules_2 >>>>>> >>>>>> I will add FreeIPA people that recently had some say about this to >>>>>> CC so >>>>>> that we can get the discussion flowing. >>>>> >>>>> Honza >>>>> >>>> >>> >> > From freeipa-github-notification at redhat.com Fri Aug 26 12:44:33 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Fri, 26 Aug 2016 14:44:33 +0200 Subject: [Freeipa-devel] [freeipa PR#28] Added a sleep interval after domainlevel raise in tests (opened) In-Reply-To: References: Message-ID: ofayans's pull request #28: "Added a sleep interval after domainlevel raise in tests" was opened PR body: """ Due to race conditions the test sometimes catches 2 one-way segments instead of one bidirectional. We need to give the master time to merge the one-way segments before we test the output. https://fedorahosted.org/freeipa/ticket/6265 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/28 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/28/head:pr28 git checkout pr28 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-28.patch URL: From freeipa-github-notification at redhat.com Fri Aug 26 12:53:02 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 14:53:02 +0200 Subject: [Freeipa-devel] [freeipa PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ On replica: ``` [root at vm-058-017 ~]# ipa-ca-install Directory Manager (existing master) password: Run connection check to master Connection check OK Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds [1/25]: creating certificate server user [2/25]: creating certificate server db [3/25]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 2 seconds elapsed Update succeeded [4/25]: creating installation admin user [5/25]: setting up certificate server [6/25]: stopping instance to update CS.cfg [7/25]: backing up CS.cfg [8/25]: disabling nonces [9/25]: set up CRL publishing [10/25]: enable PKIX certificate path discovery and validation [11/25]: set up client auth to db [12/25]: destroying installation admin user [13/25]: Ensure lightweight CAs container exists [14/25]: Configure lightweight CA key retrieval [15/25]: starting instance ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart the Dogtag instance.See the installation log for details. [16/25]: importing CA chain to RA certificate database [error] RuntimeError: Unable to retrieve CA chain: request failed with HTTP status 500 ``` ``` 2016-08-26T12:41:39Z DEBUG The CA status is: check interrupted due to error: Retrieving CA status failed with status 500 2016-08-26T12:41:39Z DEBUG Waiting for CA to start... 2016-08-26T12:41:40Z DEBUG request POST http://vm-058-017.abc.idm.lab.eng.brq.redhat.com:8080/ca/admin/ca/getStatus 2016-08-26T12:41:40Z DEBUG request body '' 2016-08-26T12:41:40Z DEBUG response status 500 2016-08-26T12:41:40Z DEBUG response headers {'content-length': '2351', 'content-language': 'en', 'server': 'Apache-Coyote/1.1', 'connection': 'close', 'date': 'Fri, 26 Aug 2016 12:41:40 GMT', 'content-type': 'te xt/html;charset=utf-8'} 2016-08-26T12:41:40Z DEBUG response body 'Apache Tomcat/8.0.32 - Error report

HTTP Status 500 - Subsystem unavailable

type Exception report

message Subsystem unavailable

description The server encountered an internal error that prevented it from fulfilling this requ est.

exception

javax.ws.rs.ServiceUnavailableException: Subsystem unavailable\n\tcom.netscape.cms.tomcat.ProxyRealm.findSecurityConstraints(ProxyRealm.java:138)\n\torg.apache.catalina.au
thenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:496)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)\n\torg.apache.catalina.valves.AbstractAccessLogValve.invoke(Abstra
ctAccessLogValve.java:616)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522)\n\torg.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1095)\n\torg.apa
che.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)\n\torg.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)\n\torg.apache.tomcat.util.net.NioEn
dpoint$SocketProcessor.run(NioEndpoint.java:1456)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:
617)\n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:745)\n

note The full stack trace of the root cause is available in the Apache Tomcat/8.0.32 logs.

Apache Tomcat/8.0.32

' 2016-08-26T12:41:40Z DEBUG The CA status is: check interrupted due to error: Retrieving CA status failed with status 500 2016-08-26T12:41:40Z DEBUG Waiting for CA to start... 2016-08-26T12:41:41Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 194, in start_instance self.start('pki-tomcat') File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 345, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 218, in start self.wait_until_running() File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 212, in wait_until_running raise RuntimeError('CA did not start in %ss' % timeout) RuntimeError: CA did not start in 300.0s ``` Debug log ``` Internal Database Error encountered: Could not connect to LDAP server host vm-058-017.abc.idm.lab.eng.brq.redhat.com port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket: org.mozilla.jss.ssl.SSLSocketException: Unable to connect: (-5961) TCP connection reset by peer. (-1) at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:676) at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1169) at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1075) at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:571) at com.netscape.certsrv.apps.CMS.init(CMS.java:187) at com.netscape.certsrv.apps.CMS.start(CMS.java:1616) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:286) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:283) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:318) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:173) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:122) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1226) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1151) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1038) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4997) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5289) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:131) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:153) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:143) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:699) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:585) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1794) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) ``` ``` [root at vm-058-017 ~]# ldapsearch -ZZ -b 'cn=directory manager' -W -x -h `hostname` ldap_start_tls: Protocol error (2) additional info: unsupported extended operation Works without SSL ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/21#issuecomment-242727129 From freeipa-github-notification at redhat.com Fri Aug 26 12:55:40 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 14:55:40 +0200 Subject: [Freeipa-devel] [freeipa PR#28] Added a sleep interval after domainlevel raise in tests (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Maybe comment next to sleep why the sleep is there, may not hurt """ See the full comment at https://github.com/freeipa/freeipa/pull/28#issuecomment-242727734 From freeipa-github-notification at redhat.com Fri Aug 26 13:02:32 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 26 Aug 2016 15:02:32 +0200 Subject: [Freeipa-devel] [freeipa PR#23] Time-Based HBAC Policies (synchronize) In-Reply-To: References: Message-ID: stlaz's pull request #23: "Time-Based HBAC Policies" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/23 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/23/head:pr23 git checkout pr23 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-23.patch URL: From freeipa-github-notification at redhat.com Fri Aug 26 13:04:38 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 26 Aug 2016 15:04:38 +0200 Subject: [Freeipa-devel] [freeipa PR#23] Time-Based HBAC Policies (synchronize) In-Reply-To: References: Message-ID: stlaz's pull request #23: "Time-Based HBAC Policies" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/23 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/23/head:pr23 git checkout pr23 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-23.patch URL: From freeipa-github-notification at redhat.com Fri Aug 26 13:21:55 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Fri, 26 Aug 2016 15:21:55 +0200 Subject: [Freeipa-devel] [freeipa PR#28] Added a sleep interval after domainlevel raise in tests (synchronize) In-Reply-To: References: Message-ID: ofayans's pull request #28: "Added a sleep interval after domainlevel raise in tests" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/28 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/28/head:pr28 git checkout pr28 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-28.patch URL: From freeipa-github-notification at redhat.com Fri Aug 26 13:22:30 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Fri, 26 Aug 2016 15:22:30 +0200 Subject: [Freeipa-devel] [freeipa PR#28] Added a sleep interval after domainlevel raise in tests (comment) In-Reply-To: References: Message-ID: ofayans commented on a pull request """ Done. """ See the full comment at https://github.com/freeipa/freeipa/pull/28#issuecomment-242733667 From freeipa-github-notification at redhat.com Fri Aug 26 14:11:05 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 16:11:05 +0200 Subject: [Freeipa-devel] [freeipa PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ I cannot connect to LDAPS even if only CA-less servers are installed """ See the full comment at https://github.com/freeipa/freeipa/pull/21#issuecomment-242746093 From freeipa-github-notification at redhat.com Fri Aug 26 14:14:26 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 16:14:26 +0200 Subject: [Freeipa-devel] [freeipa PR#28] Added a sleep interval after domainlevel raise in tests (+ack) In-Reply-To: References: Message-ID: ofayans's pull request #28: "Added a sleep interval after domainlevel raise in tests" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/28 From freeipa-github-notification at redhat.com Fri Aug 26 14:15:14 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 16:15:14 +0200 Subject: [Freeipa-devel] [freeipa PR#28] Added a sleep interval after domainlevel raise in tests (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/9dffe55e6582bca7b1a4b8ad3042c63c5ccde51a """ See the full comment at https://github.com/freeipa/freeipa/pull/28#issuecomment-242747200 From freeipa-github-notification at redhat.com Fri Aug 26 14:15:15 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 16:15:15 +0200 Subject: [Freeipa-devel] [freeipa PR#28] Added a sleep interval after domainlevel raise in tests (+pushed) In-Reply-To: References: Message-ID: ofayans's pull request #28: "Added a sleep interval after domainlevel raise in tests" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/28 From freeipa-github-notification at redhat.com Fri Aug 26 14:15:17 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 16:15:17 +0200 Subject: [Freeipa-devel] [freeipa PR#28] Added a sleep interval after domainlevel raise in tests (closed) In-Reply-To: References: Message-ID: ofayans's pull request #28: "Added a sleep interval after domainlevel raise in tests" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/28 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/28/head:pr28 git checkout pr28 From freeipa-github-notification at redhat.com Fri Aug 26 14:27:01 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Fri, 26 Aug 2016 16:27:01 +0200 Subject: [Freeipa-devel] [freeipa PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (comment) In-Reply-To: References: Message-ID: pvoborni commented on a pull request """ Promotion of replica is missing ds.enable_ssl step (or how is it called). Tomas is working on it in ticket https://fedorahosted.org/freeipa/ticket/6226 """ See the full comment at https://github.com/freeipa/freeipa/pull/21#issuecomment-242750401 From simo at redhat.com Fri Aug 26 14:29:41 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 26 Aug 2016 10:29:41 -0400 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> Message-ID: <1472221781.20746.79.camel@redhat.com> On Fri, 2016-08-26 at 11:55 +0200, Martin Basti wrote: > > On 26.08.2016 11:43, Jan Cholasta wrote: > > Hi, > > > > On 11.8.2016 12:34, Stanislav Laznicka wrote: > >> Hello, > >> > >> I updated the design of the Time-Based HBAC Policies according to the > >> discussion we led here earlier. Please check the design page > >> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest > >> changes are in the Implementation and Feature Management sections. I > >> also added a short How to Use section. > > > > 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> > > ipaMemberTimeRule > > > > > > 2) Source hosts are deprecated and thus should be removed from > > ipaHBACRuleV2. > > > > > > 3) Since time rules are defined by memberTimeRule, accessTime should > > be removed from ipaHBACRuleV2. > > ad 2) 3) > > Because backward compatibility, ipaHBACRuleV2 must contain all > attributes from ipaHBACRule as MAY > > With current approach, when timerule is added to HBAC, we just change > objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all > attributes that was defined in older HBAC. Removing any attrs from > ipaHBACRuleV2 can cause schema violation. Is there a good reason to "change" the objectclass instead of just "adding" to it ? Are v1 and v2 "incompatible" at the object lvl ? (Sorry I probably knew the answer last I looked at it but I somehow forgot). > I'm not sure if want to handle this in code (removing deprecated > attributes from HBAC entry when timerule is added) > > I realized that AccessTime is MUST for 'ipahbacrule', so when timerule > ('ipahbacrulev2') is removed and somebody deleted accesstime we have to > add it back. What is it set to these days ? Simo. > > > > > > > > 4) The CLI sections needs more work, especially for non-standard > > commands like timerule-test. > > > >> > >> On the link below is a PROTOTYPE-patched FreeIPA that covers most of the > >> CLI functionality (except for the creation of iCalendar strings from > >> options) for better illustration of the design. > >> > >> https://github.com/stlaz/freeipa/tree/timerules_2 > >> > >> I will add FreeIPA people that recently had some say about this to CC so > >> that we can get the discussion flowing. > > > > Honza > > > -- Simo Sorce * Red Hat, Inc * New York From freeipa-github-notification at redhat.com Fri Aug 26 14:30:07 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 16:30:07 +0200 Subject: [Freeipa-devel] [freeipa PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Yes, I can reproduce it without this PR. ACK for this """ See the full comment at https://github.com/freeipa/freeipa/pull/21#issuecomment-242751300 From freeipa-github-notification at redhat.com Fri Aug 26 14:30:18 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 16:30:18 +0200 Subject: [Freeipa-devel] [freeipa PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (+ack) In-Reply-To: References: Message-ID: jcholast's pull request #21: "custodia: include known CA certs in the PKCS#12 file for Dogtag" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/21 From freeipa-github-notification at redhat.com Fri Aug 26 14:31:24 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 16:31:24 +0200 Subject: [Freeipa-devel] [freeipa PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (closed) In-Reply-To: References: Message-ID: jcholast's pull request #21: "custodia: include known CA certs in the PKCS#12 file for Dogtag" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/21 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/21/head:pr21 git checkout pr21 From freeipa-github-notification at redhat.com Fri Aug 26 14:31:26 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 16:31:26 +0200 Subject: [Freeipa-devel] [freeipa PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (+pushed) In-Reply-To: References: Message-ID: jcholast's pull request #21: "custodia: include known CA certs in the PKCS#12 file for Dogtag" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/21 From freeipa-github-notification at redhat.com Fri Aug 26 14:31:27 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 16:31:27 +0200 Subject: [Freeipa-devel] [freeipa PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/6581389ac3ac1c6a0dbeb18d80e3fef69b158cc8 """ See the full comment at https://github.com/freeipa/freeipa/pull/21#issuecomment-242751639 From mbasti at redhat.com Fri Aug 26 14:39:31 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 26 Aug 2016 16:39:31 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1472221781.20746.79.camel@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <1472221781.20746.79.camel@redhat.com> Message-ID: <80ad36e9-58e2-9765-e479-bd28da7a5d9c@redhat.com> On 26.08.2016 16:29, Simo Sorce wrote: > On Fri, 2016-08-26 at 11:55 +0200, Martin Basti wrote: >> On 26.08.2016 11:43, Jan Cholasta wrote: >>> Hi, >>> >>> On 11.8.2016 12:34, Stanislav Laznicka wrote: >>>> Hello, >>>> >>>> I updated the design of the Time-Based HBAC Policies according to the >>>> discussion we led here earlier. Please check the design page >>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest >>>> changes are in the Implementation and Feature Management sections. I >>>> also added a short How to Use section. >>> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> >>> ipaMemberTimeRule >>> >>> >>> 2) Source hosts are deprecated and thus should be removed from >>> ipaHBACRuleV2. >>> >>> >>> 3) Since time rules are defined by memberTimeRule, accessTime should >>> be removed from ipaHBACRuleV2. >> ad 2) 3) >> >> Because backward compatibility, ipaHBACRuleV2 must contain all >> attributes from ipaHBACRule as MAY >> >> With current approach, when timerule is added to HBAC, we just change >> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >> attributes that was defined in older HBAC. Removing any attrs from >> ipaHBACRuleV2 can cause schema violation. > Is there a good reason to "change" the objectclass instead of just > "adding" to it ? > Are v1 and v2 "incompatible" at the object lvl ? > (Sorry I probably knew the answer last I looked at it but I somehow > forgot). Answered here: https://www.redhat.com/archives/freeipa-devel/2016-August/msg00615.html >> I'm not sure if want to handle this in code (removing deprecated >> attributes from HBAC entry when timerule is added) >> >> I realized that AccessTime is MUST for 'ipahbacrule', so when timerule >> ('ipahbacrulev2') is removed and somebody deleted accesstime we have to >> add it back. > What is it set to these days ? It was my mistake AccessTime is MAY Martin^2 > > Simo. > >> >>> >>> 4) The CLI sections needs more work, especially for non-standard >>> commands like timerule-test. >>> >>>> On the link below is a PROTOTYPE-patched FreeIPA that covers most of the >>>> CLI functionality (except for the creation of iCalendar strings from >>>> options) for better illustration of the design. >>>> >>>> https://github.com/stlaz/freeipa/tree/timerules_2 >>>> >>>> I will add FreeIPA people that recently had some say about this to CC so >>>> that we can get the discussion flowing. >>> Honza >>> > From simo at redhat.com Fri Aug 26 14:39:53 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 26 Aug 2016 10:39:53 -0400 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> Message-ID: <1472222393.20746.86.camel@redhat.com> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: > > I miss "why" part of "To be able to handle backward compatibility > with > > ease, a new object called ipaHBACRulev2 is introduced. " in the > design > > page. If the reason is the above - old client's should ignore time > rules > > then it has to be mentioned there. Otherwise I don't see a reason to > > introduce a new object type instead of extending the current. > > How do you want to enforce HBAC rule that have set time from 10 to 14 > everyday? With the same objectclass old clients will allow this HBAC > for > all day. Isn't this CVE? This is a discussion worth having. In general it is a CVE only if an authorization mechanism fails to work as advertised. If you make it clear that old clients *DO NOT* respect time rules then there is no CVE material, it is working as "described". The admins already have a way to not set those rules for older clients by simply grouping newer clients in a different host group and applying time rules only there. So the question really is: should we allow admins to apply an HBAC Rule potentially to older clients that do not understand it and will therefore allow access at any time of the day, or should we prevent it ? This is a hard question to answer and can go both ways. A time rule may be something that admins want to enforce at all cost or deny access. In this case a client that fails to handle it would be a problem. But it may be something that is just used for defense in depth and not a strictly hard requirement. In this case allowing older clients would make it an easy transition as you just set up the rule and the client will start enforcing the time when it is upgraded but work otherwise with the same rules. I am a bit conflicted on trying to decide what scenario we should target, but the second one appeals to me because host groups do already give admins a good way to apply rules to a specific set of hosts and exclude old clients w/o us making it a hard rule. OTOH if an admin does not understand this difference, they may be surprised to find out there are clients that do not honor it. Perhaps we could find a way to set a flag on the rule such that when set (and only when set) older clients get excluded by way of changing the objectlass or something else to similar effect. Open to discussion. Simo. -- Simo Sorce * Red Hat, Inc * New York From freeipa-github-notification at redhat.com Fri Aug 26 14:58:05 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Fri, 26 Aug 2016 16:58:05 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (opened) In-Reply-To: References: Message-ID: tomaskrizek's pull request #29: "Enable LDAPS in replica promotion" was opened PR body: """ With CA-less master and CA-less replica, attempting to install CA on replica would fail. LDAPS has to be enabled during replica promotion, because it is required by Dogtag. https://fedorahosted.org/freeipa/ticket/6226 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/29 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/29/head:pr29 git checkout pr29 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-29.patch URL: From freeipa-github-notification at redhat.com Fri Aug 26 15:06:44 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 26 Aug 2016 17:06:44 +0200 Subject: [Freeipa-devel] [freeipa PR#30] Print to debug output answer from CA (opened) In-Reply-To: References: Message-ID: mbasti-rh's pull request #30: "Print to debug output answer from CA" was opened PR body: """ CA request may fail due various erros, without debug output we cannot decide what is wrong. """ See the full pull-request at https://github.com/freeipa/freeipa/pull/30 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/30/head:pr30 git checkout pr30 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-30.patch URL: From abokovoy at redhat.com Fri Aug 26 15:09:43 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 26 Aug 2016 18:09:43 +0300 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1472222393.20746.86.camel@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> Message-ID: <20160826150943.5zmmub2ntc4vqqij@redhat.com> On Fri, 26 Aug 2016, Simo Sorce wrote: >On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: >> > I miss "why" part of "To be able to handle backward compatibility >> with >> > ease, a new object called ipaHBACRulev2 is introduced. " in the >> design >> > page. If the reason is the above - old client's should ignore time >> rules >> > then it has to be mentioned there. Otherwise I don't see a reason to >> > introduce a new object type instead of extending the current. >> >> How do you want to enforce HBAC rule that have set time from 10 to 14 >> everyday? With the same objectclass old clients will allow this HBAC >> for >> all day. Isn't this CVE? > >This is a discussion worth having. > >In general it is a CVE only if an authorization mechanism fails to work >as advertised. > >If you make it clear that old clients *DO NOT* respect time rules then >there is no CVE material, it is working as "described". > >The admins already have a way to not set those rules for older clients >by simply grouping newer clients in a different host group and applying >time rules only there. > >So the question really is: should we allow admins to apply an HBAC Rule >potentially to older clients that do not understand it and will >therefore allow access at any time of the day, or should we prevent it ? > >This is a hard question to answer and can go both ways. > >A time rule may be something that admins want to enforce at all cost or >deny access. In this case a client that fails to handle it would be a >problem. > >But it may be something that is just used for defense in depth and not a >strictly hard requirement. In this case allowing older clients would >make it an easy transition as you just set up the rule and the client >will start enforcing the time when it is upgraded but work otherwise >with the same rules. > >I am a bit conflicted on trying to decide what scenario we should >target, but the second one appeals to me because host groups do already >give admins a good way to apply rules to a specific set of hosts and >exclude old clients w/o us making it a hard rule. >OTOH if an admin does not understand this difference, they may be >surprised to find out there are clients that do not honor it. > >Perhaps we could find a way to set a flag on the rule such that when set >(and only when set) older clients get excluded by way of changing the >objectlass or something else to similar effect. > >Open to discussion. At this point using new object class becomes an attractive approach. We don't have means to exclude HBAC rules other than applying them per-host/hostgroup. We also have no deny rules. I have another idea: what about enforcing time rules always to apply per-host or per-hostgroup by default? Add --force option to override the behavior but default to not allow --hostcat=all. This would raise awareness and make sure admins are actually applying these rules with intention. -- / Alexander Bokovoy From simo at redhat.com Fri Aug 26 15:26:08 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 26 Aug 2016 11:26:08 -0400 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <20160826150943.5zmmub2ntc4vqqij@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> Message-ID: <1472225168.20746.95.camel@redhat.com> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: > On Fri, 26 Aug 2016, Simo Sorce wrote: > >On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: > >> > I miss "why" part of "To be able to handle backward compatibility > >> with > >> > ease, a new object called ipaHBACRulev2 is introduced. " in the > >> design > >> > page. If the reason is the above - old client's should ignore time > >> rules > >> > then it has to be mentioned there. Otherwise I don't see a reason to > >> > introduce a new object type instead of extending the current. > >> > >> How do you want to enforce HBAC rule that have set time from 10 to 14 > >> everyday? With the same objectclass old clients will allow this HBAC > >> for > >> all day. Isn't this CVE? > > > >This is a discussion worth having. > > > >In general it is a CVE only if an authorization mechanism fails to work > >as advertised. > > > >If you make it clear that old clients *DO NOT* respect time rules then > >there is no CVE material, it is working as "described". > > > >The admins already have a way to not set those rules for older clients > >by simply grouping newer clients in a different host group and applying > >time rules only there. > > > >So the question really is: should we allow admins to apply an HBAC Rule > >potentially to older clients that do not understand it and will > >therefore allow access at any time of the day, or should we prevent it ? > > > >This is a hard question to answer and can go both ways. > > > >A time rule may be something that admins want to enforce at all cost or > >deny access. In this case a client that fails to handle it would be a > >problem. > > > >But it may be something that is just used for defense in depth and not a > >strictly hard requirement. In this case allowing older clients would > >make it an easy transition as you just set up the rule and the client > >will start enforcing the time when it is upgraded but work otherwise > >with the same rules. > > > >I am a bit conflicted on trying to decide what scenario we should > >target, but the second one appeals to me because host groups do already > >give admins a good way to apply rules to a specific set of hosts and > >exclude old clients w/o us making it a hard rule. > >OTOH if an admin does not understand this difference, they may be > >surprised to find out there are clients that do not honor it. > > > >Perhaps we could find a way to set a flag on the rule such that when set > >(and only when set) older clients get excluded by way of changing the > >objectlass or something else to similar effect. > > > >Open to discussion. > At this point using new object class becomes an attractive approach. We > don't have means to exclude HBAC rules other than applying them > per-host/hostgroup. We also have no deny rules. > > I have another idea: what about enforcing time rules always to apply > per-host or per-hostgroup by default? Add --force option to override the > behavior but default to not allow --hostcat=all. This would raise > awareness and make sure admins are actually applying these rules with > intention. This sounds like a good idea, but it is not a silver bullet I am afraid. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Aug 26 15:37:34 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 26 Aug 2016 11:37:34 -0400 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1472225168.20746.95.camel@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> Message-ID: <1472225854.20746.104.camel@redhat.com> On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: > On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: > > On Fri, 26 Aug 2016, Simo Sorce wrote: > > >On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: > > >> > I miss "why" part of "To be able to handle backward compatibility > > >> with > > >> > ease, a new object called ipaHBACRulev2 is introduced. " in the > > >> design > > >> > page. If the reason is the above - old client's should ignore time > > >> rules > > >> > then it has to be mentioned there. Otherwise I don't see a reason to > > >> > introduce a new object type instead of extending the current. > > >> > > >> How do you want to enforce HBAC rule that have set time from 10 to 14 > > >> everyday? With the same objectclass old clients will allow this HBAC > > >> for > > >> all day. Isn't this CVE? > > > > > >This is a discussion worth having. > > > > > >In general it is a CVE only if an authorization mechanism fails to work > > >as advertised. > > > > > >If you make it clear that old clients *DO NOT* respect time rules then > > >there is no CVE material, it is working as "described". > > > > > >The admins already have a way to not set those rules for older clients > > >by simply grouping newer clients in a different host group and applying > > >time rules only there. > > > > > >So the question really is: should we allow admins to apply an HBAC Rule > > >potentially to older clients that do not understand it and will > > >therefore allow access at any time of the day, or should we prevent it ? > > > > > >This is a hard question to answer and can go both ways. > > > > > >A time rule may be something that admins want to enforce at all cost or > > >deny access. In this case a client that fails to handle it would be a > > >problem. > > > > > >But it may be something that is just used for defense in depth and not a > > >strictly hard requirement. In this case allowing older clients would > > >make it an easy transition as you just set up the rule and the client > > >will start enforcing the time when it is upgraded but work otherwise > > >with the same rules. > > > > > >I am a bit conflicted on trying to decide what scenario we should > > >target, but the second one appeals to me because host groups do already > > >give admins a good way to apply rules to a specific set of hosts and > > >exclude old clients w/o us making it a hard rule. > > >OTOH if an admin does not understand this difference, they may be > > >surprised to find out there are clients that do not honor it. > > > > > >Perhaps we could find a way to set a flag on the rule such that when set > > >(and only when set) older clients get excluded by way of changing the > > >objectlass or something else to similar effect. > > > > > >Open to discussion. > > At this point using new object class becomes an attractive approach. We > > don't have means to exclude HBAC rules other than applying them > > per-host/hostgroup. We also have no deny rules. > > > > I have another idea: what about enforcing time rules always to apply > > per-host or per-hostgroup by default? Add --force option to override the > > behavior but default to not allow --hostcat=all. This would raise > > awareness and make sure admins are actually applying these rules with > > intention. > > This sounds like a good idea, but it is not a silver bullet I am afraid. > > Simo. I was thinking that for future proofing we could add a version field, then reasoned more and realized that changing the object class is basically the same thing. There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, but I do not like to depend on that behavoir). Now looking into this I had an idea to solve the problem of legacy clients without having to swap classes. We can redefine the accessRuleType attribute to be a "capability" type. Ie rules that have a timeAccess component will be of type "allow_with_time" instead of just "allow". Old clients are supposed to search with accessRuleType=allow (and I can see that SSSD does that), so an older client will fail to get those rules as they won't match. New clients instead can recognize both types. Also if we need a future extension we will simpy add a new access rule type and we can have the same effect. The nice thing is that accessRyleType is defined as multivalue (no SINGLE in schema) so we may actually create compatible rules if we want to. Ie we could set both "allow" and "allow_with_time" on an object for cases where the admin wants to enforce the time part only o newer client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Aug 26 15:40:55 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 26 Aug 2016 11:40:55 -0400 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1472225854.20746.104.camel@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> Message-ID: <1472226055.20746.106.camel@redhat.com> On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote: > Ie we could set both "allow" and "allow_with_time" on an object for > cases where the admin wants to enforce the time part only o newer > client > but otherwise apply the rule to any client. I notice that SSSD does not like it if there are multiple values on this attribute, but we could change this easily in older clients when we update them. worst case the rule will not apply and admins have to create 2 rules, one with allow and one with allow_with_time. Simo. -- Simo Sorce * Red Hat, Inc * New York From freeipa-github-notification at redhat.com Fri Aug 26 22:05:59 2016 From: freeipa-github-notification at redhat.com (LiptonB) Date: Sat, 27 Aug 2016 00:05:59 +0200 Subject: [Freeipa-devel] [freeipa PR#10] Client-side CSR autogeneration (synchronize) In-Reply-To: References: Message-ID: LiptonB's pull request #10: "Client-side CSR autogeneration" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/10 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/10/head:pr10 git checkout pr10 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-10.patch URL: From freeipa-github-notification at redhat.com Fri Aug 26 22:20:57 2016 From: freeipa-github-notification at redhat.com (LiptonB) Date: Sat, 27 Aug 2016 00:20:57 +0200 Subject: [Freeipa-devel] [freeipa PR#10] Client-side CSR autogeneration (synchronize) In-Reply-To: References: Message-ID: LiptonB's pull request #10: "Client-side CSR autogeneration" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/10 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/10/head:pr10 git checkout pr10 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-10.patch URL: From blipton at redhat.com Sat Aug 27 20:40:24 2016 From: blipton at redhat.com (Ben Lipton) Date: Sat, 27 Aug 2016 16:40:24 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <57BF50E1.8030209@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <20160725111123.qthtarfgcsfbdnzk@redhat.com> <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> <57f0be1e-2915-fa33-d579-f173f1f5d019@redhat.com> <4f2f65ed-e525-1f04-f19b-c8a00b23001f@redhat.com> <57BF50E1.8030209@redhat.com> Message-ID: On 08/25/2016 04:11 PM, Rob Crittenden wrote: > Ben Lipton wrote: >> On 08/23/2016 03:54 AM, Jan Cholasta wrote: >>> On 8.8.2016 22:23, Ben Lipton wrote: >>>> On 07/25/2016 07:45 AM, Jan Cholasta wrote: >>>>> On 25.7.2016 13:11, Alexander Bokovoy wrote: >>>>>> On Mon, 25 Jul 2016, Jan Cholasta wrote: >>>>>>> On 20.7.2016 16:05, Ben Lipton wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Thanks very much for the feedback! Some responses below; I hope >>>>>>>> you'll >>>>>>>> let me know what you think of my reasoning. >>>>>>>> >>>>>>>> >>>>>>>> On 07/20/2016 04:20 AM, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 17.6.2016 00:06, Ben Lipton wrote: >>>>>>>>>> On 06/14/2016 08:27 AM, Ben Lipton wrote: >>>>>>>>>>> Hello all, >>>>>>>>>>> >>>>>>>>>>> I have written up a design proposal for making certificate >>>>>>>>>>> requests >>>>>>>>>>> easier to generate when using alternate certificate profiles: >>>>>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The use case for this is described in >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4899. I will be >>>>>>>>>>> working on >>>>>>>>>>> implementing this design over the next couple of months. If you >>>>>>>>>>> have >>>>>>>>>>> the time and interest, please take a look and share any >>>>>>>>>>> comments or >>>>>>>>>>> concerns that you have. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> Ben >>>>>>>>>>> >>>>>>>>>> Just a quick update to say that I've created a new document that >>>>>>>>>> covers >>>>>>>>>> the proposed schema additions in a more descriptive way (with >>>>>>>>>> diagrams!) >>>>>>>>>> I'm very new to developing with LDAP, so some more experienced >>>>>>>>>> eyes on >>>>>>>>>> the proposal would be very helpful, even if you don't have >>>>>>>>>> time to >>>>>>>>>> absorb the full design. Please take a look at >>>>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if you have a chance. >>>>>>>>> >>>>>>>>> I finally had a chance to take a look at this, here are some >>>>>>>>> comments: >>>>>>>>> >>>>>>>>> 1) I don't like how transformation rules are tied to a particular >>>>>>>>> helper and have to be duplicated for each of them. They should be >>>>>>>>> generic and work with any helper, as helpers are just an >>>>>>>>> implementation detail and their resulting data is the same. >>>>>>>>> >>>>>>>>> In fact, I think I would prefer if the CSR was generated using >>>>>>>>> python-cryptography's CertificateSigningRequestBuilder [1] rather >>>>>>>>> than >>>>>>>>> openssl or certutil or any other command line tool. >>>>>>>>> >>>>>>>> There are lots of tools that users might want to use to manage >>>>>>>> their >>>>>>>> private keys, so I don't know if we can assume that whatever >>>>>>>> library we >>>>>>>> prefer will actually be able to access the private key to sign a >>>>>>>> CSR, >>>>>>>> which is why I thought it would be useful to support more than >>>>>>>> one. >>>>>>> >>>>>>> python-cryptography has the notion of backends, which allow it to >>>>>>> support multiple crypto implementations. Upstream it currently >>>>>>> supports only OpenSSL [2], but some work has been done on PKCS#11 >>>>>>> backend [3], which provides support for HSMs and soft-tokens (like >>>>>>> NSS >>>>>>> databases). >>>>>>> >>>>>>> Alternatively, for NSS databases (and other "simple" cases), you >>>>>>> can >>>>>>> generate the private key with python-cryptography using the default >>>>>>> backend, export it to a file and import the file to the target >>>>>>> database, so you don't actually need the PKCS#11 backend for them. >>>>>>> >>>>>>> So, the only thing that's currently lacking is HSM support, but >>>>>>> given >>>>>>> that we don't support HSMs in IPA nor in certmonger, I don't think >>>>>>> it's an issue for now. >>>>>>> >>>>>>>> The >>>>>>>> purpose of the mapping rule is to tie together the transformation >>>>>>>> rules >>>>>>>> that produce the same data into an object that's >>>>>>>> implementation-agnostic, so that profiles referencing those rules >>>>>>>> are >>>>>>>> automatically compatible with all the helper options. >>>>>>> >>>>>>> They are implementation-agnostic, as long as you consider `openssl` >>>>>>> and `certutil` the only implementations :-) But I don't think this >>>>>>> solution scales well to other possible implementations. >>>>>>> >>>>>>> Anyway, my main grudge is that the transformation rules shouldn't >>>>>>> really be stored on and processed by the server. The server should >>>>>>> know the *what* (mapping rules), but not the *how* (transformation >>>>>>> rules). The *how* is an implementation detail and does not >>>>>>> change in >>>>>>> time, so there's no benefit in handling it on the server. It >>>>>>> should be >>>>>>> handled exclusively on the client, which I believe would also make >>>>>>> the >>>>>>> whole thing more robust (it would not be possible for a bug on the >>>>>>> server to break all the clients). >>>>>> This is a good point. However, for the scope of Ben's project can we >>>>>> limit it by openssl and certutil support? Otherwise Ben wouldn't be >>>>>> able >>>>>> to complete the project in time. >>>>> >>>>> I'm fine with that, but I don't think it's up to me :-) >>>>> >>>>>> >>>>>>>> This is turning out to be a common (and, I think, reasonable) >>>>>>>> reaction >>>>>>>> to the proposal. It is rather complex, and I worry that it will be >>>>>>>> difficult to configure. On the other hand, there is some hidden >>>>>>>> complexity to enabling a simpler config format, as well. One of >>>>>>>> the >>>>>>>> goals of the project as it was presented to me was to allow the >>>>>>>> creation >>>>>>>> of profiles that add certificate extensions *that FreeIPA doesn't >>>>>>>> yet >>>>>>>> know about*. With the current proposal, one only has to add a rule >>>>>>>> generating text that the helper will understand. >>>>>>> >>>>>>> ... which will be possible only as long as the helper >>>>>>> understands the >>>>>>> extension. Which it might not, thus the current proposal works only >>>>>>> for *some* extensions that FreeIPA doesn't yet support. >>>>>> We can go ad infinitum here but with any helper implementation, >>>>>> be it >>>>>> python-cryptography or anything else, you will need to have a >>>>>> support >>>>>> there as well. >>>>> >>>>> My point was that the current proposal is not any better than my >>>>> proposal in this regard, as neither of them allows one to use an >>>>> arbitrary extension. >>>>> >>>>>> The idea with unknown extensions was to allow mapping >>>>>> their acceptance to a specific relationship between IPA objects >>>>>> (optionally) and an input from the CSR. A simplest example would >>>>>> be an >>>>>> identity rule that would copy an ASN.1 encoded content from the >>>>>> CSR to >>>>>> the certificate. >>>>>> >>>>>> That's on the mapping side, not on the CSR generation side, but it >>>>>> would >>>>>> go similarly for the CSR if you would be able to enter unknown but >>>>>> otherwise correct ASN.1 stream. There is no difference at which >>>>>> helper >>>>>> type we are talking about because all of them support inserting >>>>>> ASN.1 >>>>>> content. >>>>>> >>>>>>>> With your suggestion, >>>>>>>> if there's a mapping between "san_directoryname" and the >>>>>>>> corresponding >>>>>>>> API calls or configuration lines, we need some way for users to >>>>>>>> augment >>>>>>>> that mapping without changing the code. If there's no mapping, and >>>>>>>> it's >>>>>>>> just done with text processing, we need enough in the config >>>>>>>> format to >>>>>>>> be able to generate fairly complex structures: >>>>>>>> >>>>>>>> builder = >>>>>>>> builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>>>>>>> builder = >>>>>>>> builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False) >>>>>>>> >>>>>>>> and we need to do it without it being equivalent to calling >>>>>>>> eval() on >>>>>>>> the config attributes. I'm not sure how to achieve this (is it >>>>>>>> safe to >>>>>>>> call getattr(x509, extensiontype)(value) where extensiontype and >>>>>>>> value >>>>>>>> are user-specified?) and it definitely would have to be tied to a >>>>>>>> particular library/tool. >>>>>>> >>>>>>> As I pointed out above, this needs to be figured out for the >>>>>>> generic >>>>>>> case for both the current proposal and my suggestion. >>>> I have a proof of concept[1] for using openssl-based rules to add a >>>> subject alt name extension without using openssl's knowledge of that >>>> extension. It's not extremely pretty, and it took some trial and >>>> error, >>>> but no code changes. So, I think this actually is a difference between >>>> the two proposals. >>> >>> With the obvious catch being that it works only with OpenSSL, which >>> might not work for everyone, e.g. when using HSMs or SmartCards, due >>> to a limited PKCS#11 support in OpenSSL. >> >> Very true. Even certutil's equivalent feature (--extGeneric) doesn't >> seem like it would work very well in this context, as you are supposed >> to pass in an already-encoded extension, so text-based templating >> wouldn't be able to do much. > > Yeah, I struggled with this myself. I ended up writing a pyasn1 script > to generate the extension I needed, wrote that to a file, and passed > it to certutil using: > > --extGeneric 2.5.29.17:not-critical:/path/to/msupn.der > >>> >>>> >>>> Next we have the easy case, extensions that we as FreeIPA developers >>>> know are important and build support for. For these, the two proposals >>>> work equivalently well, but yours is simpler to configure because the >>>> knowledge of how to make a san_rfc822name is built into the library >>>> instead of being stored on the server as a set of rules. >>>> >>>> Finally, we have the case of extensions that are known to the helper, >>>> but not to FreeIPA. In the existing proposal, new rules can be written >>>> to support these extensions under a particular helper. Further, those >>>> rules can be used by reference in many profiles, reducing >>>> duplication of >>>> effort/data/errors. >>>> >>>> As I understand it, the main objections in this thread are that >>>> transformation rules are implementation (i.e. helper) specific data >>>> stored in the IPA server, and that the system has several levels of >>>> schema when it could just embed rules in the profile. But without >>>> helper-specific rules, administrators could not take advantage of the >>>> additional extensions supported by the helper they are using. >>> >>> There is *no* advantage in forcing the user to choose between helpers >>> which differ only in the set of limitations on the CSR they are able >>> to produce. The user should specify a) where the private key is >>> located and b) what profile to use, and that's it, it should just work. >> Ok, this is a good point about usability. The user creating the CSR >> shouldn't have to care about helpers, and I agree that the current way >> they are exposed is clunky. I do think that an administrator creating >> custom rules might want to take advantage of a helper, so they wouldn't >> need to understand the ASN.1 representation of their chosen certificate >> extension. Of course, the desired extension might not be supported by >> the helper either. Since I don't know what specific extensions people >> will want to use this for, I don't know how to balance the better >> administrator experience of adding extensions via a helper with the >> limited extension support. >> >> The original reason we arrived at the concept of "helpers" was to >> support different ways of getting at private keys, but perhaps this >> should not be the concern of the CSR data generator. In your opinion, >> would it be sufficient to support just one key format (PKCS#12? PEM?) >> and let the user deal with putting those keys into whatever >> formats/databases they need? If that's ok, maybe we can stop having >> *multiple* helpers, but if we want to replace helpers entirely I'm still >> not certain what to replace them with. > > I'd just add an option to specify the output format, e.g PEM, NSS, > Java keystore, PKCS#12, whatever. You can probably get away with the > first two for starters. Different output format is going to mean > different options but that is probably not a big deal. My point was that if we want to get rid of all the helpers but one, or replace helpers with something else entirely like somehow templating ASN1 structures directly, it will get harder to support all those formats (or even both of the first two). For example, if we drop certutil as a helper, how will we sign CSRs with keys stored in NSS databases? > > Remember that the private key will be at rest for some period of time > while the CSR is being approved. The key needs to be protected at that > time. > > rob > >>> >>>> And >>>> without the separation of profiles from mapping rules in the schema, >>>> rules would need to be copy+pasted among profiles, and grouping rules >>>> with the same effect under different helpers would be much uglier. We >>>> can and should discuss whether these are the right tradeoffs, but this >>>> is where those decisions came from. >>>> >>>>>>> >>>>>>> OTOH, I think we could use GSER encoding of the extension value: >>>>>>> >>>>>>> { rfc822Name:"user at example.com", >>>>>>> directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } >>>>>> GSER is not really used widely and does not have standardized >>>>>> encoding >>>>>> rules beyond its own definition. If you want to allow transformation >>>>>> rules in GSER that mention existing content in IPA objects, you >>>>>> would >>>>>> need to deal with templating anyway. At this point it becomes >>>>>> irrelevant >>>>>> what you are templating, though. >>>>> >>>>> True, but the goal here is not to avoid templating, but rather to >>>>> avoid implementation-specific bits on the server, and GSER is the >>>>> only >>>>> thing that is textual, implementation-neutral and, as a bonus, >>>>> standardized. >>>>> >>>> As I said elsewhere, we could use GSER as a textual output format >>>> instead of openssl or certutil, but it still needs its own "helper" to >>>> build the CSR, and unlike the other options, it seems like we might >>>> need >>>> to implement that helper. I'm not sure it's fair to call it >>>> implementation-neutral if no implementation exists yet :) >>> >>> Right. Like I said, using GSER was just a quick idea off the top of my >>> head. I would actually rather use some sort of data structure >>> templating rather than textual templating on top of any kind of >>> textual representation of said data structures. I don't know if there >>> is such a thing, though. >> >> This sounds interesting, can you give an example of what this might look >> like? >> >> I learned that there's also an XML encoding for ASN.1, XER, but that's >> still a textual representation and we'd have to insert the data >> textually. It doesn't seem to be supported by any python libraries, >> either, but it does look like it's supported by the asn1 compiler in the >> IPA source distribution. I could imagine an implementation that builds >> an XML representation of the CSR via python templating, then makes a >> signed CSR out of it in C. I'm a little concerned about it because it >> would have to implement the whole CSR structure from scratch, but is >> this a prototype that you'd be interested in seeing? >> On further investigation, it turns out the version of python-cryptography in F24 includes a feature allowing arbitrary extensions to be added by adding an UnrecognizedExtension to the CertificateSigningRequestBuilder. This makes me feel somewhat better both about python-cryptography as a tool for this task and about the solution I just proposed. But I still don't have a clear idea that answers 1) how to make templates that we can turn into encoded extensions, and 2) how to deal with all the desired key formats. From ftweedal at redhat.com Mon Aug 29 05:57:40 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 29 Aug 2016 15:57:40 +1000 Subject: [Freeipa-devel] [PATCH] 0095 cert-request: allow directoryName in SAN extension In-Reply-To: References: <20160722051807.GJ10771@dhcp-40-8.bne.redhat.com> Message-ID: <20160829055740.GW3877@dhcp-40-8.bne.redhat.com> On Fri, Aug 26, 2016 at 10:41:37AM +0200, Jan Cholasta wrote: > Hi, > > On 22.7.2016 07:18, Fraser Tweedale wrote: > > While I was poking around SAN-processing code, I decided to > > implement a small enhancement: allowing the subject principal's DN > > to appear in SAN. > > > > https://fedorahosted.org/freeipa/ticket/6112 > > > > Patch depends on my other patches 0090, 0092, 0093, 0094. > > I don't think this is how DN SANs are supposed to be handled. For example, > see this bit about DN name constraints in RFC 5280 section 4.2.1.10: > > Restrictions of the form directoryName MUST be applied to the subject > field in the certificate (when the certificate includes a non-empty > subject field) and to any names of type directoryName in the > subjectAltName extension. > > It would appear to me that DN SANs only provide additional values to the > subject name of the certificate and thus should be treated the same way as > the subject name. > > We don't impose any restrictions on subject names with regard to DN of the > subject LDAP entry, so I think we should not do it for DN SANs as well. Or, > alternatively, we should do it for both. > I disagree. Supporting an altname containing the LDAP DN is a valid use case. There is no need to apply the same rules to Subject DN and Directory Name altname (otherwise, why would the Directory Name altname type even exist?). There are other possible values but this one is trivial to validate so why not? As for the RFC excerpt, this is about the Name Constraints extension. In the unlikely case that a superior certificate has a Name Constraints extension that applies to DNs, the way we construct the Subject DN is probably the bigger problem ;) Take the feature or leave it (after all, noone has asked for it yet) but IMO the usage is valid. Cheers, Fraser From freeipa-github-notification at redhat.com Mon Aug 29 06:05:40 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Mon, 29 Aug 2016 08:05:40 +0200 Subject: [Freeipa-devel] [freeipa PR#22] otptoken: Convert ipatokenotpkey on server (synchronize) In-Reply-To: References: Message-ID: dkupka's pull request #22: "otptoken: Convert ipatokenotpkey on server" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/22 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/22/head:pr22 git checkout pr22 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-22.patch URL: From freeipa-github-notification at redhat.com Mon Aug 29 06:10:51 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 29 Aug 2016 08:10:51 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (comment) In-Reply-To: References: Message-ID: jcholast commented on a pull request """ LDAPS is not enabled during replica promotion because of this condition in DS setup: https://github.com/freeipa/freeipa/blob/master/ipaserver/install/dsinstance.py#L391 Maybe we can remove the condition rather than add `ds.enable_ssl()`? """ See the full comment at https://github.com/freeipa/freeipa/pull/29#issuecomment-243039841 From jcholast at redhat.com Mon Aug 29 06:29:40 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 29 Aug 2016 08:29:40 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1472222393.20746.86.camel@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> Message-ID: <131e4f56-366a-4bce-4744-8012edb6a1f5@redhat.com> On 26.8.2016 16:39, Simo Sorce wrote: > On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: >>> I miss "why" part of "To be able to handle backward compatibility >> with >>> ease, a new object called ipaHBACRulev2 is introduced. " in the >> design >>> page. If the reason is the above - old client's should ignore time >> rules >>> then it has to be mentioned there. Otherwise I don't see a reason to >>> introduce a new object type instead of extending the current. >> >> How do you want to enforce HBAC rule that have set time from 10 to 14 >> everyday? With the same objectclass old clients will allow this HBAC >> for >> all day. Isn't this CVE? > > This is a discussion worth having. > > In general it is a CVE only if an authorization mechanism fails to work > as advertised. > > If you make it clear that old clients *DO NOT* respect time rules then > there is no CVE material, it is working as "described". > > The admins already have a way to not set those rules for older clients > by simply grouping newer clients in a different host group and applying > time rules only there. > > So the question really is: should we allow admins to apply an HBAC Rule > potentially to older clients that do not understand it and will > therefore allow access at any time of the day, or should we prevent it ? > > This is a hard question to answer and can go both ways. > > A time rule may be something that admins want to enforce at all cost or > deny access. In this case a client that fails to handle it would be a > problem. > > But it may be something that is just used for defense in depth and not a > strictly hard requirement. In this case allowing older clients would > make it an easy transition as you just set up the rule and the client > will start enforcing the time when it is upgraded but work otherwise > with the same rules. That does not make a lot of sense to me. If the admin does not really care about enforcing the access time, why would they bother setting it in the first place? > > I am a bit conflicted on trying to decide what scenario we should > target, but the second one appeals to me because host groups do already > give admins a good way to apply rules to a specific set of hosts and > exclude old clients w/o us making it a hard rule. > OTOH if an admin does not understand this difference, they may be > surprised to find out there are clients that do not honor it. The second one does not appeal to me, because it is inviting to the kind of mistakes which would allow access when it should not be allowed and IMHO it's better to be safe than sorry. > > Perhaps we could find a way to set a flag on the rule such that when set > (and only when set) older clients get excluded by way of changing the > objectlass or something else to similar effect. > > Open to discussion. > > Simo. > -- Jan Cholasta From freeipa-github-notification at redhat.com Mon Aug 29 06:42:20 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Mon, 29 Aug 2016 08:42:20 +0200 Subject: [Freeipa-devel] [freeipa PR#27] [master, ipa-4-3] Tests: Fix integration sudo tests setup and checks (comment) In-Reply-To: References: Message-ID: lslebodn commented on a pull request """ The sudo test in master (ipatests/test_integration/test_sudo.py) is the same as in 4.3 branch. And it passed for me on fedora 24 with latest ipa-4.3. I tested with sssd-1.13.4-4 (stable version in fedora) and sssd-1.14.1-1.fc24 (version in updates testing). If there is bug then it can be either in freeIPA itself or it is a timing issue in sudo_test.py -1 """ See the full comment at https://github.com/freeipa/freeipa/pull/27#issuecomment-243044097 From pspacek at redhat.com Mon Aug 29 07:13:34 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 29 Aug 2016 09:13:34 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1472226055.20746.106.camel@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1472226055.20746.106.camel@redhat.com> Message-ID: <026f6c83-5f6f-29b1-fd5d-6f4a8c3aa841@redhat.com> On 26.8.2016 17:40, Simo Sorce wrote: > On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote: >> Ie we could set both "allow" and "allow_with_time" on an object for >> cases where the admin wants to enforce the time part only o newer >> client >> but otherwise apply the rule to any client. > > I notice that SSSD does not like it if there are multiple values on this > attribute, but we could change this easily in older clients when we > update them. worst case the rule will not apply and admins have to > create 2 rules, one with allow and one with allow_with_time. I like the idea in general but it needs proper design and detailed specification first. Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object class with clear definition of "capabilities" (without any obsolete cruft). That should be future proof and without any negative impact to existing clients. -- Petr^2 Spacek From freeipa-github-notification at redhat.com Mon Aug 29 07:15:48 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Mon, 29 Aug 2016 09:15:48 +0200 Subject: [Freeipa-devel] [freeipa PR#27] [master, ipa-4-3] Tests: Fix integration sudo tests setup and checks (comment) In-Reply-To: References: Message-ID: mirielka commented on a pull request """ This PR is not intended to fix a failing test, but fix their execution and error checking. The negative tests for sudorule in master and ipa-4-3 (both with sssd-1.14.1-1.fc24, see jenkins jobs for master [1] and ipa-4-3 [2]) return following message when trying to use sudo as a user that is not allowed to use sudo by current sudorule: ``` We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. sudo: no tty present and no askpass program specified ``` As commented by pbrezina in SSSD ticket [3], this message is caused by missing sudorule "defaults" (correct one is "Sorry, user is not allowed to use sudo" or similar). Addition of this sudorule is the purpose of this PR. Also I added some checks to the contents of the error message so tests do not pass invalid error message as correct just because it has the same return code. [1] http://jenkins.idm.lab.eng.brq.redhat.com:8080/view/FreeIPA%20Integration%20-%20master%20Fedora%2024/job/freeipa-timed-integration-f24master-sudo-domlevel-0/44/consoleFull [2] http://jenkins.idm.lab.eng.brq.redhat.com:8080/view/FreeIPA%20Integration%20-%20ipa-4-3%20Fedora%2024/job/freeipa-timed-integration-f24ipa43-sudo-domlevel-0/48/consoleFull [3] https://fedorahosted.org/sssd/ticket/3152 P.S.: for me, one test in both master and ipa-4-3 fail both before and after application of this change, I would discuss it off-list with you later when I'm investigating it. Of course with Fedora 24 and sssd-1.14.1-1.fc24. """ See the full comment at https://github.com/freeipa/freeipa/pull/27#issuecomment-243049417 From freeipa-github-notification at redhat.com Mon Aug 29 08:22:09 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Mon, 29 Aug 2016 10:22:09 +0200 Subject: [Freeipa-devel] [freeipa PR#27] [master, ipa-4-3] Tests: Fix integration sudo tests setup and checks (comment) In-Reply-To: References: Message-ID: lslebodn commented on a pull request """ > This PR is not intended to fix a failing test, but fix their execution and error checking. The negative tests for sudorule in master and ipa-4-3 (both with sssd-1.14.1-1.fc24, see jenkins jobs for master [1] and ipa-4-3 [2]) return following message when trying to use sudo as a user that is not allowed to use sudo by current sudorule: Then it would be good to check error error messages with enabled and with disabled sudorule "defaults". Both are valid use-cases """ See the full comment at https://github.com/freeipa/freeipa/pull/27#issuecomment-243061957 From freeipa-github-notification at redhat.com Mon Aug 29 08:40:35 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 29 Aug 2016 10:40:35 +0200 Subject: [Freeipa-devel] [freeipa PR#22] otptoken: Convert ipatokenotpkey on server (+ack) In-Reply-To: References: Message-ID: dkupka's pull request #22: "otptoken: Convert ipatokenotpkey on server" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/22 From freeipa-github-notification at redhat.com Mon Aug 29 08:41:24 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 29 Aug 2016 10:41:24 +0200 Subject: [Freeipa-devel] [freeipa PR#22] otptoken: Convert ipatokenotpkey on server (+pushed) In-Reply-To: References: Message-ID: dkupka's pull request #22: "otptoken: Convert ipatokenotpkey on server" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/22 From freeipa-github-notification at redhat.com Mon Aug 29 08:41:25 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 29 Aug 2016 10:41:25 +0200 Subject: [Freeipa-devel] [freeipa PR#22] otptoken: Convert ipatokenotpkey on server (comment) In-Reply-To: References: Message-ID: jcholast commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/386fdc1d77affc897b923a58602a9f14325216c6 """ See the full comment at https://github.com/freeipa/freeipa/pull/22#issuecomment-243066366 From freeipa-github-notification at redhat.com Mon Aug 29 08:41:26 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 29 Aug 2016 10:41:26 +0200 Subject: [Freeipa-devel] [freeipa PR#22] otptoken: Convert ipatokenotpkey on server (closed) In-Reply-To: References: Message-ID: dkupka's pull request #22: "otptoken: Convert ipatokenotpkey on server" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/22 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/22/head:pr22 git checkout pr22 From jpazdziora at redhat.com Mon Aug 29 09:15:05 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 29 Aug 2016 11:15:05 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1472222393.20746.86.camel@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> Message-ID: <20160829091505.GA32368@redhat.com> On Fri, Aug 26, 2016 at 10:39:53AM -0400, Simo Sorce wrote: > On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: > > > > How do you want to enforce HBAC rule that have set time from 10 to 14 > > everyday? With the same objectclass old clients will allow this HBAC > > for > > all day. Isn't this CVE? > > This is a discussion worth having. > > In general it is a CVE only if an authorization mechanism fails to work > as advertised. > > If you make it clear that old clients *DO NOT* respect time rules then > there is no CVE material, it is working as "described". While that is true, it is worth helping admins to avoid creating inadvertent holes in their system. Since the rule needs some additional processing on the client, different from the old rules, it makes sense to limit exposure to these rules for old clients by technical means. Note that the URI-based access control of https://fedorahosted.org/freeipa/ticket/5030 https://www.freeipa.org/page/V4/URI-based_HBAC planned/plans to do exactly the same, to avoid wrong processing of new rules by old clients. Do you see some issue with the new object class being used? > The admins already have a way to not set those rules for older clients > by simply grouping newer clients in a different host group and applying > time rules only there. > > So the question really is: should we allow admins to apply an HBAC Rule > potentially to older clients that do not understand it and will > therefore allow access at any time of the day, or should we prevent it ? We should allow admins to apply the rule to any client and then ensure that the rule does not authorize access where it should not be allowed. Yes, access to some (old) clients will be denied even if the admin things it should be allowed. We can likely solve that problem by a note on the WebUI, about the client version requirements. That was we do not need to play games with guessing client's versions and have race situations when the admin knows they have upgraded the particular client yet IPA not knowing about it yet. > A time rule may be something that admins want to enforce at all cost or > deny access. In this case a client that fails to handle it would be a > problem. > > But it may be something that is just used for defense in depth and not a > strictly hard requirement. In this case allowing older clients would > make it an easy transition as you just set up the rule and the client > will start enforcing the time when it is upgraded but work otherwise > with the same rules. > > I am a bit conflicted on trying to decide what scenario we should > target, but the second one appeals to me because host groups do already > give admins a good way to apply rules to a specific set of hosts and > exclude old clients w/o us making it a hard rule. > OTOH if an admin does not understand this difference, they may be > surprised to find out there are clients that do not honor it. I prefer the first option. We shouldn't introduce new feature and make its behaviour ambiguous from the very start. If the access is denied for old clients when the time-based mechanism is used, at least it's a motivation to upgrade the clients. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From freeipa-github-notification at redhat.com Mon Aug 29 09:20:11 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Mon, 29 Aug 2016 11:20:11 +0200 Subject: [Freeipa-devel] [freeipa PR#31] WebUI: add support for sub-CAs while revoking certificates and removing certificate hold (opened) In-Reply-To: References: Message-ID: pvomacka's pull request #31: "WebUI: add support for sub-CAs while revoking certificates and removing certificate hold" was opened PR body: """ Revocation dialog has new field for setting a CA and these patches also fix showing details of certificates issued by sub-CAs. https://fedorahosted.org/freeipa/ticket/6216 https://fedorahosted.org/freeipa/ticket/6238 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/31 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/31/head:pr31 git checkout pr31 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-31.patch URL: From freeipa-github-notification at redhat.com Mon Aug 29 09:58:40 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Mon, 29 Aug 2016 11:58:40 +0200 Subject: [Freeipa-devel] [freeipa PR#27] [master, ipa-4-3] Tests: Fix integration sudo tests setup and checks (comment) In-Reply-To: References: Message-ID: lslebodn commented on a pull request """ I forgot to mention that it isn't necessary to it for all cases. maybe separate/new test might cover such test-case. """ See the full comment at https://github.com/freeipa/freeipa/pull/27#issuecomment-243083657 From freeipa-github-notification at redhat.com Mon Aug 29 10:02:51 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Mon, 29 Aug 2016 12:02:51 +0200 Subject: [Freeipa-devel] [freeipa PR#27] [master, ipa-4-3] Tests: Fix integration sudo tests setup and checks (comment) In-Reply-To: References: Message-ID: mirielka commented on a pull request """ Yes, I also though about not running e.g. `su -c "sudo -l" testuser` but `su -c "sudo -l -n" testuser` - it would report error `sudo: a password is required` instead of the previously pasted message that doesn't say that much... """ See the full comment at https://github.com/freeipa/freeipa/pull/27#issuecomment-243084523 From freeipa-github-notification at redhat.com Mon Aug 29 10:10:29 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Mon, 29 Aug 2016 12:10:29 +0200 Subject: [Freeipa-devel] [freeipa PR#32] Test for caacl-add-service (opened) In-Reply-To: References: Message-ID: gkaihorodova's pull request #32: "Test for caacl-add-service" was opened PR body: """ Test for caacl-add-service: incorrect error message when service does not exists https://fedorahosted.org/freeipa/ticket/6171 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/32 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/32/head:pr32 git checkout pr32 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-32.patch URL: From freeipa-github-notification at redhat.com Mon Aug 29 10:46:42 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 29 Aug 2016 12:46:42 +0200 Subject: [Freeipa-devel] [freeipa PR#14] Tests: Failing intree tests (+ack) In-Reply-To: References: Message-ID: mirielka's pull request #14: "Tests: Failing intree tests" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/14 From freeipa-github-notification at redhat.com Mon Aug 29 10:47:44 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 29 Aug 2016 12:47:44 +0200 Subject: [Freeipa-devel] [freeipa PR#14] Tests: Failing intree tests (+pushed) In-Reply-To: References: Message-ID: mirielka's pull request #14: "Tests: Failing intree tests" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/14 From freeipa-github-notification at redhat.com Mon Aug 29 10:47:46 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 29 Aug 2016 12:47:46 +0200 Subject: [Freeipa-devel] [freeipa PR#14] Tests: Failing intree tests (closed) In-Reply-To: References: Message-ID: mirielka's pull request #14: "Tests: Failing intree tests" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/14 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/14/head:pr14 git checkout pr14 From freeipa-github-notification at redhat.com Mon Aug 29 10:47:48 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 29 Aug 2016 12:47:48 +0200 Subject: [Freeipa-devel] [freeipa PR#14] Tests: Failing intree tests (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/3c32af55b646819fa8938d9a6efa6c3189525c37 https://fedorahosted.org/freeipa/changeset/774e4e479db637840cc2441778b5486d4c3b91d3 https://fedorahosted.org/freeipa/changeset/ec0a58e4845beeb14de747dbc841b5b3816a1595 """ See the full comment at https://github.com/freeipa/freeipa/pull/14#issuecomment-243092353 From freeipa-github-notification at redhat.com Mon Aug 29 10:46:01 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 29 Aug 2016 12:46:01 +0200 Subject: [Freeipa-devel] [freeipa PR#33] Update translations (opened) In-Reply-To: References: Message-ID: mbasti-rh's pull request #33: "Update translations" was opened PR body: """ """ See the full pull-request at https://github.com/freeipa/freeipa/pull/33 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/33/head:pr33 git checkout pr33 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-33.patch URL: From freeipa-github-notification at redhat.com Mon Aug 29 11:43:26 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Mon, 29 Aug 2016 13:43:26 +0200 Subject: [Freeipa-devel] [freeipa PR#26] Don't ignore --ignore-last-of-role for last CA (comment) In-Reply-To: References: Message-ID: ofayans commented on a pull request """ QA ACK. With these changes the issue is gone """ See the full comment at https://github.com/freeipa/freeipa/pull/26#issuecomment-243101582 From freeipa-github-notification at redhat.com Mon Aug 29 11:43:42 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Mon, 29 Aug 2016 13:43:42 +0200 Subject: [Freeipa-devel] [freeipa PR#26] Don't ignore --ignore-last-of-role for last CA (+ack) In-Reply-To: References: Message-ID: stlaz's pull request #26: "Don't ignore --ignore-last-of-role for last CA" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/26 From freeipa-github-notification at redhat.com Mon Aug 29 11:47:10 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 29 Aug 2016 13:47:10 +0200 Subject: [Freeipa-devel] [freeipa PR#26] Don't ignore --ignore-last-of-role for last CA (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/f0487946cd760a97d92aac12d98cf8bb748576a2 """ See the full comment at https://github.com/freeipa/freeipa/pull/26#issuecomment-243102220 From freeipa-github-notification at redhat.com Mon Aug 29 11:47:11 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 29 Aug 2016 13:47:11 +0200 Subject: [Freeipa-devel] [freeipa PR#26] Don't ignore --ignore-last-of-role for last CA (+pushed) In-Reply-To: References: Message-ID: stlaz's pull request #26: "Don't ignore --ignore-last-of-role for last CA" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/26 From freeipa-github-notification at redhat.com Mon Aug 29 11:47:13 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 29 Aug 2016 13:47:13 +0200 Subject: [Freeipa-devel] [freeipa PR#26] Don't ignore --ignore-last-of-role for last CA (closed) In-Reply-To: References: Message-ID: stlaz's pull request #26: "Don't ignore --ignore-last-of-role for last CA" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/26 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/26/head:pr26 git checkout pr26 From freeipa-github-notification at redhat.com Mon Aug 29 12:27:55 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 29 Aug 2016 14:27:55 +0200 Subject: [Freeipa-devel] [freeipa PR#34] dns: prompt for missing record parts in CLI (opened) In-Reply-To: References: Message-ID: jcholast's pull request #34: " dns: prompt for missing record parts in CLI" was opened PR body: """ Fix the code which determines if a record part is required and thus should be prompted not to wrongfully consider all record parts to be optional. Add a client-side fallback of the dnsrecord_split_parts command for old servers to avoid CommandError in dnsrecord_add and dnsrecord_mod CLI interactive mode. https://fedorahosted.org/freeipa/ticket/6203 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/34 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/34/head:pr34 git checkout pr34 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-34.patch URL: From freeipa-github-notification at redhat.com Mon Aug 29 12:38:44 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 29 Aug 2016 14:38:44 +0200 Subject: [Freeipa-devel] [freeipa PR#34] dns: prompt for missing record parts in CLI (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ I really don't like to move definitions how to split params from classes to single function ``` def split_rrparam(name, value): ``` It doesn't look safe for me or easy to understand and maintain. When I want to add new DNS type, I have to check 3 different files, I'm sure I will overlook something. """ See the full comment at https://github.com/freeipa/freeipa/pull/34#issuecomment-243112068 From freeipa-github-notification at redhat.com Mon Aug 29 12:50:21 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 29 Aug 2016 14:50:21 +0200 Subject: [Freeipa-devel] [freeipa PR#35] rpcserver: assume version 1 for unversioned command calls (opened) In-Reply-To: References: Message-ID: jcholast's pull request #35: "rpcserver: assume version 1 for unversioned command calls" was opened PR body: """ When a command is called on the server over RPC without its version specified, assume version 1 instead of the highest known version. This ensures backward compatibility with old clients, which do not support versioned commands and understand only the first version of any given command. https://fedorahosted.org/freeipa/ticket/6217 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/35 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/35/head:pr35 git checkout pr35 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-35.patch URL: From freeipa-github-notification at redhat.com Mon Aug 29 12:51:33 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 29 Aug 2016 14:51:33 +0200 Subject: [Freeipa-devel] [freeipa PR#34] dns: prompt for missing record parts in CLI (comment) In-Reply-To: References: Message-ID: jcholast commented on a pull request """ I'm afraid this can't be easily fixed due to the manner in which the dns plugin is implemented. I'm open to suggestions if you have any. """ See the full comment at https://github.com/freeipa/freeipa/pull/34#issuecomment-243114929 From freeipa-github-notification at redhat.com Mon Aug 29 13:00:01 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 29 Aug 2016 15:00:01 +0200 Subject: [Freeipa-devel] [freeipa PR#20] cert: include CA name in cert command output (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ test_xmlrpc/test_cert_plugin.py ........F.........................F.... 2 same internal errors: ``` [Mon Aug 29 14:57:07.951307 2016] [wsgi:error] [pid 66778] ipa: ERROR: non-public: KeyError: ipapython.dn.DN('CN=SMIME CA,O=test industries Inc.') [Mon Aug 29 14:57:07.951339 2016] [wsgi:error] [pid 66778] Traceback (most recent call last): [Mon Aug 29 14:57:07.951342 2016] [wsgi:error] [pid 66778] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 352, in wsgi_execute [Mon Aug 29 14:57:07.951345 2016] [wsgi:error] [pid 66778] result = self.Command[name](*args, **options) [Mon Aug 29 14:57:07.951348 2016] [wsgi:error] [pid 66778] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ [Mon Aug 29 14:57:07.951351 2016] [wsgi:error] [pid 66778] return self.__do_call(*args, **options) [Mon Aug 29 14:57:07.951353 2016] [wsgi:error] [pid 66778] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call [Mon Aug 29 14:57:07.951356 2016] [wsgi:error] [pid 66778] ret = self.run(*args, **options) [Mon Aug 29 14:57:07.951380 2016] [wsgi:error] [pid 66778] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run [Mon Aug 29 14:57:07.951383 2016] [wsgi:error] [pid 66778] return self.execute(*args, **options) [Mon Aug 29 14:57:07.951385 2016] [wsgi:error] [pid 66778] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1347, in execute [Mon Aug 29 14:57:07.951388 2016] [wsgi:error] [pid 66778] **options) [Mon Aug 29 14:57:07.951391 2016] [wsgi:error] [pid 66778] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1227, in _ca_search [Mon Aug 29 14:57:07.951406 2016] [wsgi:error] [pid 66778] obj['cacn'] = cas[issuer]['cn'][0] [Mon Aug 29 14:57:07.951410 2016] [wsgi:error] [pid 66778] KeyError: ipapython.dn.DN('CN=SMIME CA,O=test industries Inc.') ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/20#issuecomment-243116953 From freeipa-github-notification at redhat.com Mon Aug 29 13:13:23 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 29 Aug 2016 15:13:23 +0200 Subject: [Freeipa-devel] [freeipa PR#20] cert: include CA name in cert command output (synchronize) In-Reply-To: References: Message-ID: jcholast's pull request #20: "cert: include CA name in cert command output" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/20 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/20/head:pr20 git checkout pr20 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-20.patch URL: From freeipa-github-notification at redhat.com Mon Aug 29 14:09:02 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Mon, 29 Aug 2016 16:09:02 +0200 Subject: [Freeipa-devel] [freeipa PR#27] [master, ipa-4-3] Tests: Fix integration sudo tests setup and checks (synchronize) In-Reply-To: References: Message-ID: mirielka's pull request #27: "[master, ipa-4-3] Tests: Fix integration sudo tests setup and checks" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/27 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/27/head:pr27 git checkout pr27 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-27.patch URL: From freeipa-github-notification at redhat.com Mon Aug 29 14:31:11 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 29 Aug 2016 16:31:11 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (synchronize) In-Reply-To: References: Message-ID: tomaskrizek's pull request #29: "Enable LDAPS in replica promotion" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/29 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/29/head:pr29 git checkout pr29 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-29.patch URL: From simo at redhat.com Mon Aug 29 14:33:15 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 29 Aug 2016 10:33:15 -0400 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <131e4f56-366a-4bce-4744-8012edb6a1f5@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <131e4f56-366a-4bce-4744-8012edb6a1f5@redhat.com> Message-ID: <1472481195.20746.122.camel@redhat.com> On Mon, 2016-08-29 at 08:29 +0200, Jan Cholasta wrote: > On 26.8.2016 16:39, Simo Sorce wrote: > > On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: > >>> I miss "why" part of "To be able to handle backward compatibility > >> with > >>> ease, a new object called ipaHBACRulev2 is introduced. " in the > >> design > >>> page. If the reason is the above - old client's should ignore time > >> rules > >>> then it has to be mentioned there. Otherwise I don't see a reason to > >>> introduce a new object type instead of extending the current. > >> > >> How do you want to enforce HBAC rule that have set time from 10 to 14 > >> everyday? With the same objectclass old clients will allow this HBAC > >> for > >> all day. Isn't this CVE? > > > > This is a discussion worth having. > > > > In general it is a CVE only if an authorization mechanism fails to work > > as advertised. > > > > If you make it clear that old clients *DO NOT* respect time rules then > > there is no CVE material, it is working as "described". > > > > The admins already have a way to not set those rules for older clients > > by simply grouping newer clients in a different host group and applying > > time rules only there. > > > > So the question really is: should we allow admins to apply an HBAC Rule > > potentially to older clients that do not understand it and will > > therefore allow access at any time of the day, or should we prevent it ? > > > > This is a hard question to answer and can go both ways. > > > > A time rule may be something that admins want to enforce at all cost or > > deny access. In this case a client that fails to handle it would be a > > problem. > > > > But it may be something that is just used for defense in depth and not a > > strictly hard requirement. In this case allowing older clients would > > make it an easy transition as you just set up the rule and the client > > will start enforcing the time when it is upgraded but work otherwise > > with the same rules. > > That does not make a lot of sense to me. If the admin does not really > care about enforcing the access time, why would they bother setting it > in the first place? It's not that they do not care, but life is not black and white and sometimes you need to compromise, so you restrict what you can and let the rest keep working, as client upgrades slide in situation will improve. > > I am a bit conflicted on trying to decide what scenario we should > > target, but the second one appeals to me because host groups do already > > give admins a good way to apply rules to a specific set of hosts and > > exclude old clients w/o us making it a hard rule. > > OTOH if an admin does not understand this difference, they may be > > surprised to find out there are clients that do not honor it. > > The second one does not appeal to me, because it is inviting to the kind > of mistakes which would allow access when it should not be allowed and > IMHO it's better to be safe than sorry. As a general advice yes, but we need to care about other things, like usability, and progression. We did not have time rules at all till now, so allowing smooth upgrades is important I think. The nice think about using accessRuleType is that we can set a good default and then let admins to decide, I like that a lot as it keeps admins in control and does not force behavior. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Aug 29 14:34:43 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 29 Aug 2016 10:34:43 -0400 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <026f6c83-5f6f-29b1-fd5d-6f4a8c3aa841@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1472226055.20746.106.camel@redhat.com> <026f6c83-5f6f-29b1-fd5d-6f4a8c3aa841@redhat.com> Message-ID: <1472481283.20746.124.camel@redhat.com> On Mon, 2016-08-29 at 09:13 +0200, Petr Spacek wrote: > On 26.8.2016 17:40, Simo Sorce wrote: > > On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote: > >> Ie we could set both "allow" and "allow_with_time" on an object for > >> cases where the admin wants to enforce the time part only o newer > >> client > >> but otherwise apply the rule to any client. > > > > I notice that SSSD does not like it if there are multiple values on this > > attribute, but we could change this easily in older clients when we > > update them. worst case the rule will not apply and admins have to > > create 2 rules, one with allow and one with allow_with_time. > > I like the idea in general but it needs proper design and detailed > specification first. > > Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object > class with clear definition of "capabilities" (without any obsolete cruft). > > That should be future proof and without any negative impact to existing clients. ipaHBACRule2 is needed anyway, it is just how it is implemented that differs, I really think we should go the accessRuleType route, I find it superior to messing with objects by ripping off structural objectclasses and replacing them. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Mon Aug 29 14:35:39 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 29 Aug 2016 16:35:39 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1472481283.20746.124.camel@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1472226055.20746.106.camel@redhat.com> <026f6c83-5f6f-29b1-fd5d-6f4a8c3aa841@redhat.com> <1472481283.20746.124.camel@redhat.com> Message-ID: <3336d4a3-7e57-c052-fa63-7408c2bb1639@redhat.com> On 29.8.2016 16:34, Simo Sorce wrote: > On Mon, 2016-08-29 at 09:13 +0200, Petr Spacek wrote: >> On 26.8.2016 17:40, Simo Sorce wrote: >>> On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote: >>>> Ie we could set both "allow" and "allow_with_time" on an object for >>>> cases where the admin wants to enforce the time part only o newer >>>> client >>>> but otherwise apply the rule to any client. >>> >>> I notice that SSSD does not like it if there are multiple values on this >>> attribute, but we could change this easily in older clients when we >>> update them. worst case the rule will not apply and admins have to >>> create 2 rules, one with allow and one with allow_with_time. >> >> I like the idea in general but it needs proper design and detailed >> specification first. >> >> Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object >> class with clear definition of "capabilities" (without any obsolete cruft). >> >> That should be future proof and without any negative impact to existing clients. > > ipaHBACRule2 is needed anyway, it is just how it is implemented that > differs, I really think we should go the accessRuleType route, I find it > superior to messing with objects by ripping off structural objectclasses > and replacing them. So we are in agreement ;-) -- Petr^2 Spacek From simo at redhat.com Mon Aug 29 14:47:18 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 29 Aug 2016 10:47:18 -0400 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <20160829091505.GA32368@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160829091505.GA32368@redhat.com> Message-ID: <1472482038.20746.129.camel@redhat.com> On Mon, 2016-08-29 at 11:15 +0200, Jan Pazdziora wrote: > On Fri, Aug 26, 2016 at 10:39:53AM -0400, Simo Sorce wrote: > > On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: > > > > > > How do you want to enforce HBAC rule that have set time from 10 to 14 > > > everyday? With the same objectclass old clients will allow this HBAC > > > for > > > all day. Isn't this CVE? > > > > This is a discussion worth having. > > > > In general it is a CVE only if an authorization mechanism fails to work > > as advertised. > > > > If you make it clear that old clients *DO NOT* respect time rules then > > there is no CVE material, it is working as "described". > > While that is true, it is worth helping admins to avoid creating > inadvertent holes in their system. Since the rule needs some > additional processing on the client, different from the old rules, it > makes sense to limit exposure to these rules for old clients by > technical means. > > Note that the URI-based access control of > > https://fedorahosted.org/freeipa/ticket/5030 > https://www.freeipa.org/page/V4/URI-based_HBAC > > planned/plans to do exactly the same, to avoid wrong processing of new > rules by old clients. > > Do you see some issue with the new object class being used? > > > The admins already have a way to not set those rules for older clients > > by simply grouping newer clients in a different host group and applying > > time rules only there. > > > > So the question really is: should we allow admins to apply an HBAC Rule > > potentially to older clients that do not understand it and will > > therefore allow access at any time of the day, or should we prevent it ? > > We should allow admins to apply the rule to any client and then > ensure that the rule does not authorize access where it should not be > allowed. Yes, access to some (old) clients will be denied even if the > admin things it should be allowed. We can likely solve that problem by > a note on the WebUI, about the client version requirements. > > That was we do not need to play games with guessing client's versions > and have race situations when the admin knows they have upgraded the > particular client yet IPA not knowing about it yet. > > > A time rule may be something that admins want to enforce at all cost or > > deny access. In this case a client that fails to handle it would be a > > problem. > > > > But it may be something that is just used for defense in depth and not a > > strictly hard requirement. In this case allowing older clients would > > make it an easy transition as you just set up the rule and the client > > will start enforcing the time when it is upgraded but work otherwise > > with the same rules. > > > > I am a bit conflicted on trying to decide what scenario we should > > target, but the second one appeals to me because host groups do already > > give admins a good way to apply rules to a specific set of hosts and > > exclude old clients w/o us making it a hard rule. > > OTOH if an admin does not understand this difference, they may be > > surprised to find out there are clients that do not honor it. > > I prefer the first option. We shouldn't introduce new feature and make > its behaviour ambiguous from the very start. > > If the access is denied for old clients when the time-based mechanism > is used, at least it's a motivation to upgrade the clients. All good arguments except the last one. We are not here to make admins lices difficult, we are here to make them better. They are often stuck with older OS version for reasons beyond their control, so we need to give them options not aut-auts Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Aug 29 14:51:17 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 29 Aug 2016 10:51:17 -0400 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <3336d4a3-7e57-c052-fa63-7408c2bb1639@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1472226055.20746.106.camel@redhat.com> <026f6c83-5f6f-29b1-fd5d-6f4a8c3aa841@redhat.com> <1472481283.20746.124.camel@redhat.com> <3336d4a3-7e57-c052-fa63-7408c2bb1639@redhat.com> Message-ID: <1472482277.20746.130.camel@redhat.com> On Mon, 2016-08-29 at 16:35 +0200, Petr Spacek wrote: > On 29.8.2016 16:34, Simo Sorce wrote: > > On Mon, 2016-08-29 at 09:13 +0200, Petr Spacek wrote: > >> On 26.8.2016 17:40, Simo Sorce wrote: > >>> On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote: > >>>> Ie we could set both "allow" and "allow_with_time" on an object for > >>>> cases where the admin wants to enforce the time part only o newer > >>>> client > >>>> but otherwise apply the rule to any client. > >>> > >>> I notice that SSSD does not like it if there are multiple values on this > >>> attribute, but we could change this easily in older clients when we > >>> update them. worst case the rule will not apply and admins have to > >>> create 2 rules, one with allow and one with allow_with_time. > >> > >> I like the idea in general but it needs proper design and detailed > >> specification first. > >> > >> Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object > >> class with clear definition of "capabilities" (without any obsolete cruft). > >> > >> That should be future proof and without any negative impact to existing clients. > > > > ipaHBACRule2 is needed anyway, it is just how it is implemented that > > differs, I really think we should go the accessRuleType route, I find it > > superior to messing with objects by ripping off structural objectclasses > > and replacing them. > > So we are in agreement ;-) If you liked my proposal then I guess we are, it wasn't clear to me :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From freeipa-github-notification at redhat.com Mon Aug 29 15:02:22 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 29 Aug 2016 17:02:22 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (synchronize) In-Reply-To: References: Message-ID: tomaskrizek's pull request #29: "Enable LDAPS in replica promotion" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/29 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/29/head:pr29 git checkout pr29 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-29.patch URL: From freeipa-github-notification at redhat.com Mon Aug 29 15:07:39 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 29 Aug 2016 17:07:39 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (comment) In-Reply-To: References: Message-ID: tomaskrizek commented on a pull request """ @jcholast I'm not certain that enabling the LDAPS before replication finishes won't have some unintended side effects. """ See the full comment at https://github.com/freeipa/freeipa/pull/29#issuecomment-243152442 From freeipa-github-notification at redhat.com Mon Aug 29 15:14:37 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 29 Aug 2016 17:14:37 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (comment) In-Reply-To: References: Message-ID: tomaskrizek commented on a pull request """ @jcholast I'm not certain that enabling the LDAPS before replica promotion finishes won't have some unintended side effects. """ See the full comment at https://github.com/freeipa/freeipa/pull/29#issuecomment-243152442 From freeipa-github-notification at redhat.com Mon Aug 29 15:19:14 2016 From: freeipa-github-notification at redhat.com (simo5) Date: Mon, 29 Aug 2016 17:19:14 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (comment) In-Reply-To: References: Message-ID: simo5 commented on a pull request """ @jcholast we can't enable ssl there as the cert is not available yet, look a few lines later: https://github.com/freeipa/freeipa/blob/master/ipaserver/install/dsinstance.py#L397 """ See the full comment at https://github.com/freeipa/freeipa/pull/29#issuecomment-243155959 From freeipa-github-notification at redhat.com Mon Aug 29 15:20:31 2016 From: freeipa-github-notification at redhat.com (simo5) Date: Mon, 29 Aug 2016 17:20:31 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (comment) In-Reply-To: References: Message-ID: simo5 commented on a pull request """ That said we should probably enable_ssl righ tafter we get the cert and restart DS, and not in replicainstall.py """ See the full comment at https://github.com/freeipa/freeipa/pull/29#issuecomment-243156343 From freeipa-github-notification at redhat.com Mon Aug 29 15:48:11 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 29 Aug 2016 17:48:11 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (synchronize) In-Reply-To: References: Message-ID: tomaskrizek's pull request #29: "Enable LDAPS in replica promotion" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/29 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/29/head:pr29 git checkout pr29 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-29.patch URL: From freeipa-github-notification at redhat.com Mon Aug 29 15:49:11 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 29 Aug 2016 17:49:11 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (comment) In-Reply-To: References: Message-ID: tomaskrizek commented on a pull request """ I've updated the PR based on the comments, please review. """ See the full comment at https://github.com/freeipa/freeipa/pull/29#issuecomment-243164916 From freeipa-github-notification at redhat.com Mon Aug 29 16:22:00 2016 From: freeipa-github-notification at redhat.com (simo5) Date: Mon, 29 Aug 2016 18:22:00 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (comment) In-Reply-To: References: Message-ID: simo5 commented on a pull request """ LGTM """ See the full comment at https://github.com/freeipa/freeipa/pull/29#issuecomment-243174342 From mbabinsk at redhat.com Mon Aug 29 16:39:58 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 29 Aug 2016 18:39:58 +0200 Subject: [Freeipa-devel] [PATCH] 0100 Track lightweight CAs on replica installation In-Reply-To: <20160823064043.GD3877@dhcp-40-8.bne.redhat.com> References: <20160823064043.GD3877@dhcp-40-8.bne.redhat.com> Message-ID: On 08/23/2016 08:40 AM, Fraser Tweedale wrote: > Hi folks, > > Please review attached patch which fixes > https://fedorahosted.org/freeipa/ticket/6019. > > Thanks, > Fraser > > > Hi Fraser, I have couple of comments: 1.) - for entry in lwcas: - self.server_track_lightweight_ca(entry) + try: + from ipaserver.install import cainstance + cainstance.add_lightweight_ca_tracking_requests(self.log, lwcas) + except Exception as e: + self.log.exception( + "Failed to add lightweight CA tracking requests") You are importing a server-side module in a basically client-side command which I don't like very much. Isn't there a possibility to use shared client-server module for this? 2.) + def __add_lightweight_ca_tracking_requests(self): + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) + is_already_connected = conn.isconnected() Why use these connection setup shenanigans when you can use either api.Backend.ldap2 (IIRC this runs in server context so LDAPI should be a given) or even the service's own 'admin_conn' member. + + if not is_already_connected: + try: + conn.connect(autobind=True) + except errors.PublicError as e: + self.log.error( + "Cannot connect to LDAP to add " + "lightweight CA tracking requests: %s", + e + ) PEP8 error here, the second line of the message is misformatted. + return + + try: + lwcas = conn.get_entries( + base_dn=ipautil.realm_to_suffix(api.env.realm), + filter='(objectclass=ipaca)', + attrs_list=['cn', 'ipacaid'], + ) I would rather use the result of api.Command.ca_find to fetch sub-CAs. Also, ipautil.realm_to_suffix is superseded by api.env.basedn to fetch search base. + add_lightweight_ca_tracking_requests(self.log, lwcas) + except errors.NotFound: + pass # shouldn't happen, but don't fail if it does I would add at least some debug message here. + finally: + if not is_already_connected: + conn.disconnect() + -- Martin^3 Babinsky From freeipa-github-notification at redhat.com Tue Aug 30 05:57:50 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 30 Aug 2016 07:57:50 +0200 Subject: [Freeipa-devel] [freeipa PR#36] Fix tests for forward zones (opened) In-Reply-To: References: Message-ID: pspacek's pull request #36: "Fix tests for forward zones" was opened PR body: """ """ See the full pull-request at https://github.com/freeipa/freeipa/pull/36 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/36/head:pr36 git checkout pr36 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-36.patch URL: From freeipa-github-notification at redhat.com Tue Aug 30 06:13:58 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 30 Aug 2016 08:13:58 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (+ack) In-Reply-To: References: Message-ID: tomaskrizek's pull request #29: "Enable LDAPS in replica promotion" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/29 From freeipa-github-notification at redhat.com Tue Aug 30 06:14:25 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 30 Aug 2016 08:14:25 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (+pushed) In-Reply-To: References: Message-ID: tomaskrizek's pull request #29: "Enable LDAPS in replica promotion" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/29 From freeipa-github-notification at redhat.com Tue Aug 30 06:14:26 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 30 Aug 2016 08:14:26 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (closed) In-Reply-To: References: Message-ID: tomaskrizek's pull request #29: "Enable LDAPS in replica promotion" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/29 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/29/head:pr29 git checkout pr29 From freeipa-github-notification at redhat.com Tue Aug 30 06:14:28 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 30 Aug 2016 08:14:28 +0200 Subject: [Freeipa-devel] [freeipa PR#29] Enable LDAPS in replica promotion (comment) In-Reply-To: References: Message-ID: jcholast commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/89de60c5d8ba64d619101a7498b8c4469b6e50ae """ See the full comment at https://github.com/freeipa/freeipa/pull/29#issuecomment-243343065 From freeipa-github-notification at redhat.com Tue Aug 30 06:21:54 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 30 Aug 2016 08:21:54 +0200 Subject: [Freeipa-devel] [freeipa PR#3] User add fix #6199 (+ack) In-Reply-To: References: Message-ID: mbasti-rh's pull request #3: "User add fix #6199" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/3 From freeipa-github-notification at redhat.com Tue Aug 30 06:22:18 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 30 Aug 2016 08:22:18 +0200 Subject: [Freeipa-devel] [freeipa PR#3] User add fix #6199 (+pushed) In-Reply-To: References: Message-ID: mbasti-rh's pull request #3: "User add fix #6199" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/3 From freeipa-github-notification at redhat.com Tue Aug 30 06:22:19 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 30 Aug 2016 08:22:19 +0200 Subject: [Freeipa-devel] [freeipa PR#3] User add fix #6199 (closed) In-Reply-To: References: Message-ID: mbasti-rh's pull request #3: "User add fix #6199" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/3 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/3/head:pr3 git checkout pr3 From freeipa-github-notification at redhat.com Tue Aug 30 06:22:21 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 30 Aug 2016 08:22:21 +0200 Subject: [Freeipa-devel] [freeipa PR#3] User add fix #6199 (comment) In-Reply-To: References: Message-ID: jcholast commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/5c50b265e6b5a0d06f213b5eb581c96e3392aeea """ See the full comment at https://github.com/freeipa/freeipa/pull/3#issuecomment-243344321 From freeipa-github-notification at redhat.com Tue Aug 30 06:24:13 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 30 Aug 2016 08:24:13 +0200 Subject: [Freeipa-devel] [freeipa PR#37] cert: add missing param values to cert-find output (opened) In-Reply-To: References: Message-ID: jcholast's pull request #37: "cert: add missing param values to cert-find output" was opened PR body: """ Add back `serial_number_hex` and `revoked` param values to cert-find output accidentally removed in commit c718ef058847bb39e78236e8af0ad69ac961bbcf. https://fedorahosted.org/freeipa/ticket/6269 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/37 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/37/head:pr37 git checkout pr37 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-37.patch URL: From freeipa-github-notification at redhat.com Tue Aug 30 06:34:52 2016 From: freeipa-github-notification at redhat.com (abbra) Date: Tue, 30 Aug 2016 08:34:52 +0200 Subject: [Freeipa-devel] [freeipa PR#37] cert: add missing param values to cert-find output (comment) In-Reply-To: References: Message-ID: abbra commented on a pull request """ LGTM. """ See the full comment at https://github.com/freeipa/freeipa/pull/37#issuecomment-243346328 From freeipa-github-notification at redhat.com Tue Aug 30 06:35:01 2016 From: freeipa-github-notification at redhat.com (abbra) Date: Tue, 30 Aug 2016 08:35:01 +0200 Subject: [Freeipa-devel] [freeipa PR#37] cert: add missing param values to cert-find output (+ack) In-Reply-To: References: Message-ID: jcholast's pull request #37: "cert: add missing param values to cert-find output" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/37 From jcholast at redhat.com Tue Aug 30 06:48:58 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 30 Aug 2016 08:48:58 +0200 Subject: [Freeipa-devel] [PATCH] 0095 cert-request: allow directoryName in SAN extension In-Reply-To: <20160829055740.GW3877@dhcp-40-8.bne.redhat.com> References: <20160722051807.GJ10771@dhcp-40-8.bne.redhat.com> <20160829055740.GW3877@dhcp-40-8.bne.redhat.com> Message-ID: On 29.8.2016 07:57, Fraser Tweedale wrote: > On Fri, Aug 26, 2016 at 10:41:37AM +0200, Jan Cholasta wrote: >> Hi, >> >> On 22.7.2016 07:18, Fraser Tweedale wrote: >>> While I was poking around SAN-processing code, I decided to >>> implement a small enhancement: allowing the subject principal's DN >>> to appear in SAN. >>> >>> https://fedorahosted.org/freeipa/ticket/6112 >>> >>> Patch depends on my other patches 0090, 0092, 0093, 0094. >> >> I don't think this is how DN SANs are supposed to be handled. For example, >> see this bit about DN name constraints in RFC 5280 section 4.2.1.10: >> >> Restrictions of the form directoryName MUST be applied to the subject >> field in the certificate (when the certificate includes a non-empty >> subject field) and to any names of type directoryName in the >> subjectAltName extension. >> >> It would appear to me that DN SANs only provide additional values to the >> subject name of the certificate and thus should be treated the same way as >> the subject name. >> >> We don't impose any restrictions on subject names with regard to DN of the >> subject LDAP entry, so I think we should not do it for DN SANs as well. Or, >> alternatively, we should do it for both. >> > I disagree. Supporting an altname containing the LDAP DN is a valid > use case. There is no need to apply the same rules to Subject DN > and Directory Name altname Nowhere in the RFC is it stated that there is any semantic difference between the subject name and DN SANs, so I don't see why should we make DN SANs special. > (otherwise, why would the Directory Name > altname type even exist?). To allow multiple subject DNs. > There are other possible values but this > one is trivial to validate so why not? I have no issue with validation per se, I just find it very odd that the code would allow me to request a cert with any LDAP entry DN in subject name but only one specific LDAP entry DN in DN SAN. > > As for the RFC excerpt, this is about the Name Constraints > extension. In the unlikely case that a superior certificate has a > Name Constraints extension that applies to DNs, the way we construct > the Subject DN is probably the bigger problem ;) Yes, this particular excerpt is about name constraints, but I doubt that if you looked anywhere else, it would say something different about the relationship of subject name and DN SANs. > > Take the feature or leave it (after all, noone has asked for it yet) > but IMO the usage is valid. > > Cheers, > Fraser > -- Jan Cholasta From slaznick at redhat.com Tue Aug 30 06:47:00 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Tue, 30 Aug 2016 08:47:00 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1472225854.20746.104.camel@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> Message-ID: <1a254cbc-120f-1645-6a4e-20ef5563719f@redhat.com> On 08/26/2016 05:37 PM, Simo Sorce wrote: > On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: >> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: >>> On Fri, 26 Aug 2016, Simo Sorce wrote: >>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: >>>>>> I miss "why" part of "To be able to handle backward compatibility >>>>> with >>>>>> ease, a new object called ipaHBACRulev2 is introduced. " in the >>>>> design >>>>>> page. If the reason is the above - old client's should ignore time >>>>> rules >>>>>> then it has to be mentioned there. Otherwise I don't see a reason to >>>>>> introduce a new object type instead of extending the current. >>>>> How do you want to enforce HBAC rule that have set time from 10 to 14 >>>>> everyday? With the same objectclass old clients will allow this HBAC >>>>> for >>>>> all day. Isn't this CVE? >>>> This is a discussion worth having. >>>> >>>> In general it is a CVE only if an authorization mechanism fails to work >>>> as advertised. >>>> >>>> If you make it clear that old clients *DO NOT* respect time rules then >>>> there is no CVE material, it is working as "described". >>>> >>>> The admins already have a way to not set those rules for older clients >>>> by simply grouping newer clients in a different host group and applying >>>> time rules only there. >>>> >>>> So the question really is: should we allow admins to apply an HBAC Rule >>>> potentially to older clients that do not understand it and will >>>> therefore allow access at any time of the day, or should we prevent it ? >>>> >>>> This is a hard question to answer and can go both ways. >>>> >>>> A time rule may be something that admins want to enforce at all cost or >>>> deny access. In this case a client that fails to handle it would be a >>>> problem. >>>> >>>> But it may be something that is just used for defense in depth and not a >>>> strictly hard requirement. In this case allowing older clients would >>>> make it an easy transition as you just set up the rule and the client >>>> will start enforcing the time when it is upgraded but work otherwise >>>> with the same rules. >>>> >>>> I am a bit conflicted on trying to decide what scenario we should >>>> target, but the second one appeals to me because host groups do already >>>> give admins a good way to apply rules to a specific set of hosts and >>>> exclude old clients w/o us making it a hard rule. >>>> OTOH if an admin does not understand this difference, they may be >>>> surprised to find out there are clients that do not honor it. >>>> >>>> Perhaps we could find a way to set a flag on the rule such that when set >>>> (and only when set) older clients get excluded by way of changing the >>>> objectlass or something else to similar effect. >>>> >>>> Open to discussion. >>> At this point using new object class becomes an attractive approach. We >>> don't have means to exclude HBAC rules other than applying them >>> per-host/hostgroup. We also have no deny rules. >>> >>> I have another idea: what about enforcing time rules always to apply >>> per-host or per-hostgroup by default? Add --force option to override the >>> behavior but default to not allow --hostcat=all. This would raise >>> awareness and make sure admins are actually applying these rules with >>> intention. >> This sounds like a good idea, but it is not a silver bullet I am afraid. >> >> Simo. > I was thinking that for future proofing we could add a version field, > then reasoned more and realized that changing the object class is > basically the same thing. > > There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass. > (I know 389ds allows us to do an LDAPv3 illegal operation and change it, > but I do not like to depend on that behavoir). > > Now looking into this I had an idea to solve the problem of legacy > clients without having to swap classes. > We can redefine the accessRuleType attribute to be a "capability" type. > > Ie rules that have a timeAccess component will be of type > "allow_with_time" instead of just "allow". > Old clients are supposed to search with accessRuleType=allow (and I can > see that SSSD does that), so an older client will fail to get those > rules as they won't match. > > New clients instead can recognize both types. > > Also if we need a future extension we will simpy add a new access rule > type and we can have the same effect. > The nice thing is that accessRyleType is defined as multivalue (no > SINGLE in schema) so we may actually create compatible rules if we want > to. > Ie we could set both "allow" and "allow_with_time" on an object for > cases where the admin wants to enforce the time part only o newer client > but otherwise apply the rule to any client. > > This should give us the best of all options at once. > > Thoughts ? > > Simo. > Sorry to join the discussion so late, I was away yesterday. I have to say I too like this idea much better than fiddling with the objectClasses. Also, I believe that accessRuleType was originally actually used to distinguish newer version of HBAC rules from the older so we may just do this again and profit from its original purpose. To top it off, this change should be really easy to implement to what I currently have on SSSD side. I was just wondering - would you propose for every newly created rule to have the new accessRuleType set to "allow_with_time" or should the type change with addition of time rules to the HBAC rule as it does currently? Also, should the user be able to modify the type so that a rule with the new type is also visible for older clients (=> he could add "allow" to type anytime)? Thanks for your ideas, I am very happy with what you suggested here :) From jcholast at redhat.com Tue Aug 30 07:01:44 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 30 Aug 2016 09:01:44 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1a254cbc-120f-1645-6a4e-20ef5563719f@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1a254cbc-120f-1645-6a4e-20ef5563719f@redhat.com> Message-ID: <22d981eb-b51a-4325-ee93-d0023aa5ead8@redhat.com> On 30.8.2016 08:47, Standa Laznicka wrote: > On 08/26/2016 05:37 PM, Simo Sorce wrote: >> On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: >>> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: >>>> On Fri, 26 Aug 2016, Simo Sorce wrote: >>>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: >>>>>>> I miss "why" part of "To be able to handle backward compatibility >>>>>> with >>>>>>> ease, a new object called ipaHBACRulev2 is introduced. " in the >>>>>> design >>>>>>> page. If the reason is the above - old client's should ignore time >>>>>> rules >>>>>>> then it has to be mentioned there. Otherwise I don't see a reason to >>>>>>> introduce a new object type instead of extending the current. >>>>>> How do you want to enforce HBAC rule that have set time from 10 to 14 >>>>>> everyday? With the same objectclass old clients will allow this HBAC >>>>>> for >>>>>> all day. Isn't this CVE? >>>>> This is a discussion worth having. >>>>> >>>>> In general it is a CVE only if an authorization mechanism fails to >>>>> work >>>>> as advertised. >>>>> >>>>> If you make it clear that old clients *DO NOT* respect time rules then >>>>> there is no CVE material, it is working as "described". >>>>> >>>>> The admins already have a way to not set those rules for older clients >>>>> by simply grouping newer clients in a different host group and >>>>> applying >>>>> time rules only there. >>>>> >>>>> So the question really is: should we allow admins to apply an HBAC >>>>> Rule >>>>> potentially to older clients that do not understand it and will >>>>> therefore allow access at any time of the day, or should we prevent >>>>> it ? >>>>> >>>>> This is a hard question to answer and can go both ways. >>>>> >>>>> A time rule may be something that admins want to enforce at all >>>>> cost or >>>>> deny access. In this case a client that fails to handle it would be a >>>>> problem. >>>>> >>>>> But it may be something that is just used for defense in depth and >>>>> not a >>>>> strictly hard requirement. In this case allowing older clients would >>>>> make it an easy transition as you just set up the rule and the client >>>>> will start enforcing the time when it is upgraded but work otherwise >>>>> with the same rules. >>>>> >>>>> I am a bit conflicted on trying to decide what scenario we should >>>>> target, but the second one appeals to me because host groups do >>>>> already >>>>> give admins a good way to apply rules to a specific set of hosts and >>>>> exclude old clients w/o us making it a hard rule. >>>>> OTOH if an admin does not understand this difference, they may be >>>>> surprised to find out there are clients that do not honor it. >>>>> >>>>> Perhaps we could find a way to set a flag on the rule such that >>>>> when set >>>>> (and only when set) older clients get excluded by way of changing the >>>>> objectlass or something else to similar effect. >>>>> >>>>> Open to discussion. >>>> At this point using new object class becomes an attractive approach. We >>>> don't have means to exclude HBAC rules other than applying them >>>> per-host/hostgroup. We also have no deny rules. >>>> >>>> I have another idea: what about enforcing time rules always to apply >>>> per-host or per-hostgroup by default? Add --force option to override >>>> the >>>> behavior but default to not allow --hostcat=all. This would raise >>>> awareness and make sure admins are actually applying these rules with >>>> intention. >>> This sounds like a good idea, but it is not a silver bullet I am afraid. >>> >>> Simo. >> I was thinking that for future proofing we could add a version field, >> then reasoned more and realized that changing the object class is >> basically the same thing. >> >> There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass. >> (I know 389ds allows us to do an LDAPv3 illegal operation and change it, >> but I do not like to depend on that behavoir). >> >> Now looking into this I had an idea to solve the problem of legacy >> clients without having to swap classes. >> We can redefine the accessRuleType attribute to be a "capability" type. >> >> Ie rules that have a timeAccess component will be of type >> "allow_with_time" instead of just "allow". >> Old clients are supposed to search with accessRuleType=allow (and I can >> see that SSSD does that), so an older client will fail to get those >> rules as they won't match. >> >> New clients instead can recognize both types. >> >> Also if we need a future extension we will simpy add a new access rule >> type and we can have the same effect. >> The nice thing is that accessRyleType is defined as multivalue (no >> SINGLE in schema) so we may actually create compatible rules if we want >> to. >> Ie we could set both "allow" and "allow_with_time" on an object for >> cases where the admin wants to enforce the time part only o newer client >> but otherwise apply the rule to any client. >> >> This should give us the best of all options at once. >> >> Thoughts ? >> >> Simo. >> > Sorry to join the discussion so late, I was away yesterday. > > I have to say I too like this idea much better than fiddling with the > objectClasses. Note that the resulting code will be exactly the same except for the attribute name - you won't be fiddling with objectClass but with attributeRuleType. > Also, I believe that accessRuleType was originally > actually used to distinguish newer version of HBAC rules from the older > so we may just do this again and profit from its original purpose. The original purpose was to support deny rules, but they were deprecated. > To > top it off, this change should be really easy to implement to what I > currently have on SSSD side. > > I was just wondering - would you propose for every newly created rule to > have the new accessRuleType set to "allow_with_time" or should the type > change with addition of time rules to the HBAC rule as it does > currently? Also, should the user be able to modify the type so that a > rule with the new type is also visible for older clients (=> he could > add "allow" to type anytime)? > > Thanks for your ideas, I am very happy with what you suggested here :) TBH I'm not - I don't find adding hacks on top of obsolete deprecated stuff to be a particularly appealing solution to anything. -- Jan Cholasta From freeipa-github-notification at redhat.com Tue Aug 30 07:15:23 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 30 Aug 2016 09:15:23 +0200 Subject: [Freeipa-devel] [freeipa PR#25] Added install check before executing ipa-* command (comment) In-Reply-To: References: Message-ID: tomaskrizek commented on a pull request """ The following commands still fail with incorrect error message: - `ipa trust-find` - `ipa-compat-manage` - `ipa-csreplica-manage list` - `ipa-join` - `ipa-ldap-updater` - `ipa-replica-install` - `ipa-restore` Details: ``` [root at master vagrant]# ipa trust-find ipa: ERROR: cannot connect to 'http://localhost:8888/ipa/json': [Errno 111] Connection refused [root at master vagrant]# ipa-compat-manage An IPA server to update cannot be found. Has one been configured yet? The error was: IPA realm not found in DNS, in the config file (/etc/ipa/default.conf) or on the command line. [root at master vagrant]# ipa-csreplica-manage list Directory Manager password: unexpected error: cannot connect to 'ldap://localhost:389': [root at master vagrant]# ipa-join cannot open configuration file /etc/ipa/default.conf Unable to determine IPA server from /etc/ipa/default.conf [root at master vagrant]# ipa-ldap-updater To execute overall IPA upgrade please use 'ipa-server-upgrade' command No update files or schema file were specified The ipa-ldap-updater command failed. See /var/log/ipaupgrade.log for more information [root at master vagrant]# ipa-replica-install Configuring client side components One of password / principal / keytab is required. Installation failed. Rolling back changes. IPA client is not configured on this system. Removing client side components IPA client is not configured on this system. Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROR Configuration of client side components failed! ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information [root at master vagrant]# ipa-restore Usage: ipa-restore [options] backup ipa-restore: error: must provide the backup to restore The ipa-restore command failed. See /var/log/iparestore.log for more information ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/25#issuecomment-243353391 From jcholast at redhat.com Tue Aug 30 07:27:00 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 30 Aug 2016 09:27:00 +0200 Subject: [Freeipa-devel] [PATCH] 0220 move /bin/ipa to freeipa-client In-Reply-To: <20160825110930.vimskikhtn2lwmmy@redhat.com> References: <20160825092720.242twohhey7pf2vs@redhat.com> <25322a89-9557-7790-7f81-af1aedcc8807@redhat.com> <20160825110930.vimskikhtn2lwmmy@redhat.com> Message-ID: On 25.8.2016 13:09, Alexander Bokovoy wrote: > On Thu, 25 Aug 2016, Jan Cholasta wrote: >> Hi, >> >> On 25.8.2016 11:27, Alexander Bokovoy wrote: >>> Hi, >>> >>> attached patch moves ipa CLI to freeipa-client and obsoletes >>> freeipa-admintools >> >> The Obsoletes (both) should be on version < 4.4.1 rather than >> %{version}, as per Fedora packaging guidelines [1]. >> >> Please move the Obsoletes and Provides on %{name}-admintools right >> below Group (Obsoletes first) and put a newline between the >> %{alt_name}-client and %{alt_name}-admintools blocks, for consistent >> layout accross all subpackages in the spec file. >> >>> >>> Solves https://fedorahosted.org/freeipa/ticket/5934 >>> >>> Here is how upgrade looks when running 'dnf': >>> >>> Upgrading: >>> freeipa-client x86_64 >>> 4.4.0.201608250913GIT9c20682-0.fc24 @commandline >>> 146 k >>> replacing freeipa-admintools.noarch >>> 4.4.0.201608051228GIT590e30f-0.fc24 >> >> I'm going to test with yum as well, for RHEL and CentOS. > Updated patch attached. Thanks, ACK. Pushed to master: b91ba39d627d36d1a62ebf97a987a2579404395e -- Jan Cholasta From abokovoy at redhat.com Tue Aug 30 07:23:17 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 30 Aug 2016 10:23:17 +0300 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <22d981eb-b51a-4325-ee93-d0023aa5ead8@redhat.com> References: <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1a254cbc-120f-1645-6a4e-20ef5563719f@redhat.com> <22d981eb-b51a-4325-ee93-d0023aa5ead8@redhat.com> Message-ID: <20160830072317.dz6ugrwdxgb3qtna@redhat.com> On Tue, 30 Aug 2016, Jan Cholasta wrote: >On 30.8.2016 08:47, Standa Laznicka wrote: >>On 08/26/2016 05:37 PM, Simo Sorce wrote: >>>On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: >>>>On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: >>>>>On Fri, 26 Aug 2016, Simo Sorce wrote: >>>>>>On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: >>>>>>>>I miss "why" part of "To be able to handle backward compatibility >>>>>>>with >>>>>>>>ease, a new object called ipaHBACRulev2 is introduced. " in the >>>>>>>design >>>>>>>>page. If the reason is the above - old client's should ignore time >>>>>>>rules >>>>>>>>then it has to be mentioned there. Otherwise I don't see a reason to >>>>>>>>introduce a new object type instead of extending the current. >>>>>>>How do you want to enforce HBAC rule that have set time from 10 to 14 >>>>>>>everyday? With the same objectclass old clients will allow this HBAC >>>>>>>for >>>>>>>all day. Isn't this CVE? >>>>>>This is a discussion worth having. >>>>>> >>>>>>In general it is a CVE only if an authorization mechanism fails to >>>>>>work >>>>>>as advertised. >>>>>> >>>>>>If you make it clear that old clients *DO NOT* respect time rules then >>>>>>there is no CVE material, it is working as "described". >>>>>> >>>>>>The admins already have a way to not set those rules for older clients >>>>>>by simply grouping newer clients in a different host group and >>>>>>applying >>>>>>time rules only there. >>>>>> >>>>>>So the question really is: should we allow admins to apply an HBAC >>>>>>Rule >>>>>>potentially to older clients that do not understand it and will >>>>>>therefore allow access at any time of the day, or should we prevent >>>>>>it ? >>>>>> >>>>>>This is a hard question to answer and can go both ways. >>>>>> >>>>>>A time rule may be something that admins want to enforce at all >>>>>>cost or >>>>>>deny access. In this case a client that fails to handle it would be a >>>>>>problem. >>>>>> >>>>>>But it may be something that is just used for defense in depth and >>>>>>not a >>>>>>strictly hard requirement. In this case allowing older clients would >>>>>>make it an easy transition as you just set up the rule and the client >>>>>>will start enforcing the time when it is upgraded but work otherwise >>>>>>with the same rules. >>>>>> >>>>>>I am a bit conflicted on trying to decide what scenario we should >>>>>>target, but the second one appeals to me because host groups do >>>>>>already >>>>>>give admins a good way to apply rules to a specific set of hosts and >>>>>>exclude old clients w/o us making it a hard rule. >>>>>>OTOH if an admin does not understand this difference, they may be >>>>>>surprised to find out there are clients that do not honor it. >>>>>> >>>>>>Perhaps we could find a way to set a flag on the rule such that >>>>>>when set >>>>>>(and only when set) older clients get excluded by way of changing the >>>>>>objectlass or something else to similar effect. >>>>>> >>>>>>Open to discussion. >>>>>At this point using new object class becomes an attractive approach. We >>>>>don't have means to exclude HBAC rules other than applying them >>>>>per-host/hostgroup. We also have no deny rules. >>>>> >>>>>I have another idea: what about enforcing time rules always to apply >>>>>per-host or per-hostgroup by default? Add --force option to override >>>>>the >>>>>behavior but default to not allow --hostcat=all. This would raise >>>>>awareness and make sure admins are actually applying these rules with >>>>>intention. >>>>This sounds like a good idea, but it is not a silver bullet I am afraid. >>>> >>>>Simo. >>>I was thinking that for future proofing we could add a version field, >>>then reasoned more and realized that changing the object class is >>>basically the same thing. >>> >>>There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass. >>>(I know 389ds allows us to do an LDAPv3 illegal operation and change it, >>>but I do not like to depend on that behavoir). >>> >>>Now looking into this I had an idea to solve the problem of legacy >>>clients without having to swap classes. >>>We can redefine the accessRuleType attribute to be a "capability" type. >>> >>>Ie rules that have a timeAccess component will be of type >>>"allow_with_time" instead of just "allow". >>>Old clients are supposed to search with accessRuleType=allow (and I can >>>see that SSSD does that), so an older client will fail to get those >>>rules as they won't match. >>> >>>New clients instead can recognize both types. >>> >>>Also if we need a future extension we will simpy add a new access rule >>>type and we can have the same effect. >>>The nice thing is that accessRyleType is defined as multivalue (no >>>SINGLE in schema) so we may actually create compatible rules if we want >>>to. >>>Ie we could set both "allow" and "allow_with_time" on an object for >>>cases where the admin wants to enforce the time part only o newer client >>>but otherwise apply the rule to any client. >>> >>>This should give us the best of all options at once. >>> >>>Thoughts ? >>> >>>Simo. >>> >>Sorry to join the discussion so late, I was away yesterday. >> >>I have to say I too like this idea much better than fiddling with the >>objectClasses. > >Note that the resulting code will be exactly the same except for the >attribute name - you won't be fiddling with objectClass but with >attributeRuleType. > >>Also, I believe that accessRuleType was originally >>actually used to distinguish newer version of HBAC rules from the older >>so we may just do this again and profit from its original purpose. > >The original purpose was to support deny rules, but they were deprecated. > >>To >>top it off, this change should be really easy to implement to what I >>currently have on SSSD side. >> >>I was just wondering - would you propose for every newly created rule to >>have the new accessRuleType set to "allow_with_time" or should the type >>change with addition of time rules to the HBAC rule as it does >>currently? Also, should the user be able to modify the type so that a >>rule with the new type is also visible for older clients (=> he could >>add "allow" to type anytime)? >> >>Thanks for your ideas, I am very happy with what you suggested here :) > >TBH I'm not - I don't find adding hacks on top of obsolete deprecated >stuff to be a particularly appealing solution to anything. It is just an attribute. Reusing an attribute that is not used anymore for anything else is not a bad thing. The original solution may be deprecated but the schema is in place and will be almost forever, so using otherwise unused but present schema is just fine. -- / Alexander Bokovoy From slaznick at redhat.com Tue Aug 30 07:34:34 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Tue, 30 Aug 2016 09:34:34 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <20160830072317.dz6ugrwdxgb3qtna@redhat.com> References: <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1a254cbc-120f-1645-6a4e-20ef5563719f@redhat.com> <22d981eb-b51a-4325-ee93-d0023aa5ead8@redhat.com> <20160830072317.dz6ugrwdxgb3qtna@redhat.com> Message-ID: On 08/30/2016 09:23 AM, Alexander Bokovoy wrote: > On Tue, 30 Aug 2016, Jan Cholasta wrote: >> On 30.8.2016 08:47, Standa Laznicka wrote: >>> On 08/26/2016 05:37 PM, Simo Sorce wrote: >>>> On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: >>>>> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: >>>>>> On Fri, 26 Aug 2016, Simo Sorce wrote: >>>>>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: >>>>>>>>> I miss "why" part of "To be able to handle backward compatibility >>>>>>>> with >>>>>>>>> ease, a new object called ipaHBACRulev2 is introduced. " in the >>>>>>>> design >>>>>>>>> page. If the reason is the above - old client's should ignore >>>>>>>>> time >>>>>>>> rules >>>>>>>>> then it has to be mentioned there. Otherwise I don't see a >>>>>>>>> reason to >>>>>>>>> introduce a new object type instead of extending the current. >>>>>>>> How do you want to enforce HBAC rule that have set time from 10 >>>>>>>> to 14 >>>>>>>> everyday? With the same objectclass old clients will allow this >>>>>>>> HBAC >>>>>>>> for >>>>>>>> all day. Isn't this CVE? >>>>>>> This is a discussion worth having. >>>>>>> >>>>>>> In general it is a CVE only if an authorization mechanism fails to >>>>>>> work >>>>>>> as advertised. >>>>>>> >>>>>>> If you make it clear that old clients *DO NOT* respect time >>>>>>> rules then >>>>>>> there is no CVE material, it is working as "described". >>>>>>> >>>>>>> The admins already have a way to not set those rules for older >>>>>>> clients >>>>>>> by simply grouping newer clients in a different host group and >>>>>>> applying >>>>>>> time rules only there. >>>>>>> >>>>>>> So the question really is: should we allow admins to apply an HBAC >>>>>>> Rule >>>>>>> potentially to older clients that do not understand it and will >>>>>>> therefore allow access at any time of the day, or should we prevent >>>>>>> it ? >>>>>>> >>>>>>> This is a hard question to answer and can go both ways. >>>>>>> >>>>>>> A time rule may be something that admins want to enforce at all >>>>>>> cost or >>>>>>> deny access. In this case a client that fails to handle it would >>>>>>> be a >>>>>>> problem. >>>>>>> >>>>>>> But it may be something that is just used for defense in depth and >>>>>>> not a >>>>>>> strictly hard requirement. In this case allowing older clients >>>>>>> would >>>>>>> make it an easy transition as you just set up the rule and the >>>>>>> client >>>>>>> will start enforcing the time when it is upgraded but work >>>>>>> otherwise >>>>>>> with the same rules. >>>>>>> >>>>>>> I am a bit conflicted on trying to decide what scenario we should >>>>>>> target, but the second one appeals to me because host groups do >>>>>>> already >>>>>>> give admins a good way to apply rules to a specific set of hosts >>>>>>> and >>>>>>> exclude old clients w/o us making it a hard rule. >>>>>>> OTOH if an admin does not understand this difference, they may be >>>>>>> surprised to find out there are clients that do not honor it. >>>>>>> >>>>>>> Perhaps we could find a way to set a flag on the rule such that >>>>>>> when set >>>>>>> (and only when set) older clients get excluded by way of >>>>>>> changing the >>>>>>> objectlass or something else to similar effect. >>>>>>> >>>>>>> Open to discussion. >>>>>> At this point using new object class becomes an attractive >>>>>> approach. We >>>>>> don't have means to exclude HBAC rules other than applying them >>>>>> per-host/hostgroup. We also have no deny rules. >>>>>> >>>>>> I have another idea: what about enforcing time rules always to apply >>>>>> per-host or per-hostgroup by default? Add --force option to override >>>>>> the >>>>>> behavior but default to not allow --hostcat=all. This would raise >>>>>> awareness and make sure admins are actually applying these rules >>>>>> with >>>>>> intention. >>>>> This sounds like a good idea, but it is not a silver bullet I am >>>>> afraid. >>>>> >>>>> Simo. >>>> I was thinking that for future proofing we could add a version field, >>>> then reasoned more and realized that changing the object class is >>>> basically the same thing. >>>> >>>> There is only one big problem, ipaHBACRule is a STRUCTURAL >>>> objectclass. >>>> (I know 389ds allows us to do an LDAPv3 illegal operation and >>>> change it, >>>> but I do not like to depend on that behavoir). >>>> >>>> Now looking into this I had an idea to solve the problem of legacy >>>> clients without having to swap classes. >>>> We can redefine the accessRuleType attribute to be a "capability" >>>> type. >>>> >>>> Ie rules that have a timeAccess component will be of type >>>> "allow_with_time" instead of just "allow". >>>> Old clients are supposed to search with accessRuleType=allow (and I >>>> can >>>> see that SSSD does that), so an older client will fail to get those >>>> rules as they won't match. >>>> >>>> New clients instead can recognize both types. >>>> >>>> Also if we need a future extension we will simpy add a new access rule >>>> type and we can have the same effect. >>>> The nice thing is that accessRyleType is defined as multivalue (no >>>> SINGLE in schema) so we may actually create compatible rules if we >>>> want >>>> to. >>>> Ie we could set both "allow" and "allow_with_time" on an object for >>>> cases where the admin wants to enforce the time part only o newer >>>> client >>>> but otherwise apply the rule to any client. >>>> >>>> This should give us the best of all options at once. >>>> >>>> Thoughts ? >>>> >>>> Simo. >>>> >>> Sorry to join the discussion so late, I was away yesterday. >>> >>> I have to say I too like this idea much better than fiddling with the >>> objectClasses. >> >> Note that the resulting code will be exactly the same except for the >> attribute name - you won't be fiddling with objectClass but with >> attributeRuleType. I do realize that (even though I touched this in my first question) but this solution seems a bit cleaner to me. >> >>> Also, I believe that accessRuleType was originally >>> actually used to distinguish newer version of HBAC rules from the older >>> so we may just do this again and profit from its original purpose. >> >> The original purpose was to support deny rules, but they were >> deprecated. >> >>> To >>> top it off, this change should be really easy to implement to what I >>> currently have on SSSD side. >>> >>> I was just wondering - would you propose for every newly created >>> rule to >>> have the new accessRuleType set to "allow_with_time" or should the type >>> change with addition of time rules to the HBAC rule as it does >>> currently? Also, should the user be able to modify the type so that a >>> rule with the new type is also visible for older clients (=> he could >>> add "allow" to type anytime)? >>> >>> Thanks for your ideas, I am very happy with what you suggested here :) >> >> TBH I'm not - I don't find adding hacks on top of obsolete deprecated >> stuff to be a particularly appealing solution to anything. > It is just an attribute. Reusing an attribute that is not used anymore > for anything else is not a bad thing. The original solution may be > deprecated but the schema is in place and will be almost forever, so > using otherwise unused but present schema is just fine. > +1, why not to use it if there's no other use for it anyway. From freeipa-github-notification at redhat.com Tue Aug 30 07:35:03 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 09:35:03 +0200 Subject: [Freeipa-devel] [freeipa PR#34] dns: prompt for missing record parts in CLI (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Can we move DNS record classes to ipalib/dnsrecords.py and use it in both client and server? IMO for server side code it should work just fine, not sure about client. """ See the full comment at https://github.com/freeipa/freeipa/pull/34#issuecomment-243357356 From mbabinsk at redhat.com Tue Aug 30 07:56:19 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 30 Aug 2016 09:56:19 +0200 Subject: [Freeipa-devel] [PATCH] 0101 Add ca-disable and ca-enable commands In-Reply-To: <20160825082523.GM3877@dhcp-40-8.bne.redhat.com> References: <20160825082523.GM3877@dhcp-40-8.bne.redhat.com> Message-ID: <2ecd524c-94aa-e492-aeb8-b1b8fab2135c@redhat.com> On 08/25/2016 10:25 AM, Fraser Tweedale wrote: > Hi team, > > The attached patch fixes > https://fedorahosted.org/freeipa/ticket/6257. > > The behaviour of cert-request when the CA is disabled is not very > nice (it reports a server error from Dogtag). The Dogtag REST > interface gives much better errors so I plan to move to it in a > later change (which will also address > https://fedorahosted.org/freeipa/ticket/3473, in part). > > Thanks, > Fraser > > > HI Fraser, I have a couple of comments below: 1.) @@ -25,6 +33,10 @@ EXAMPLES: ipa ca-add puppet --desc "Puppet" \\ --subject "CN=Puppet CA,O=EXAMPLE.COM" + Disable a CA. + + ipa ca-disable puppet + """) You missed an example of `ca-enable` command in the doc string. 2.) Regarding implementation of ca_enable/disable, I think you can reduce the amount of code duplication by employing a base class which will look up the required sub-CA and call the RA backend method required by the subclass. See the attached untested diff (passes lint) for details. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: example.patch Type: text/x-patch Size: 2239 bytes Desc: not available URL: From jcholast at redhat.com Tue Aug 30 08:09:56 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 30 Aug 2016 10:09:56 +0200 Subject: [Freeipa-devel] [PATCH] 0101 Add ca-disable and ca-enable commands In-Reply-To: <2ecd524c-94aa-e492-aeb8-b1b8fab2135c@redhat.com> References: <20160825082523.GM3877@dhcp-40-8.bne.redhat.com> <2ecd524c-94aa-e492-aeb8-b1b8fab2135c@redhat.com> Message-ID: <10af7aea-68d8-49c2-b712-85969b5b2079@redhat.com> Hi, On 30.8.2016 09:56, Martin Babinsky wrote: > On 08/25/2016 10:25 AM, Fraser Tweedale wrote: >> Hi team, >> >> The attached patch fixes >> https://fedorahosted.org/freeipa/ticket/6257. >> >> The behaviour of cert-request when the CA is disabled is not very >> nice (it reports a server error from Dogtag). The Dogtag REST >> interface gives much better errors so I plan to move to it in a >> later change (which will also address >> https://fedorahosted.org/freeipa/ticket/3473, in part). >> >> Thanks, >> Fraser >> >> >> > > HI Fraser, > > I have a couple of comments below: > > 1.) > @@ -25,6 +33,10 @@ EXAMPLES: > ipa ca-add puppet --desc "Puppet" \\ > --subject "CN=Puppet CA,O=EXAMPLE.COM" > > + Disable a CA. > + > + ipa ca-disable puppet > + > """) > > You missed an example of `ca-enable` command in the doc string. > > 2.) > > Regarding implementation of ca_enable/disable, I think you can reduce > the amount of code duplication by employing a base class which will look > up the required sub-CA and call the RA backend method required by the > subclass. See the attached untested diff (passes lint) for details. NACK, please don't use getattr() this way. Since you are subclassing here, you should use polymorphism: class CAQuery(LDAPQuery): def execute(...): ... self.perform_action(ca_api, ca_id) ... def perform_action(self, ca_api, ca_id): raise NotImplementedError() class ca_enable(CAQuery): def perform_action(self, ca_api, ca_id): ca_api.enable_ca(ca_id) Honza -- Jan Cholasta From mbabinsk at redhat.com Tue Aug 30 08:23:10 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 30 Aug 2016 10:23:10 +0200 Subject: [Freeipa-devel] [PATCH] 0101 Add ca-disable and ca-enable commands In-Reply-To: <10af7aea-68d8-49c2-b712-85969b5b2079@redhat.com> References: <20160825082523.GM3877@dhcp-40-8.bne.redhat.com> <2ecd524c-94aa-e492-aeb8-b1b8fab2135c@redhat.com> <10af7aea-68d8-49c2-b712-85969b5b2079@redhat.com> Message-ID: <3db9b05b-5bfa-ddf6-daeb-5e2be57beca9@redhat.com> On 08/30/2016 10:09 AM, Jan Cholasta wrote: > Hi, > > On 30.8.2016 09:56, Martin Babinsky wrote: >> On 08/25/2016 10:25 AM, Fraser Tweedale wrote: >>> Hi team, >>> >>> The attached patch fixes >>> https://fedorahosted.org/freeipa/ticket/6257. >>> >>> The behaviour of cert-request when the CA is disabled is not very >>> nice (it reports a server error from Dogtag). The Dogtag REST >>> interface gives much better errors so I plan to move to it in a >>> later change (which will also address >>> https://fedorahosted.org/freeipa/ticket/3473, in part). >>> >>> Thanks, >>> Fraser >>> >>> >>> >> >> HI Fraser, >> >> I have a couple of comments below: >> >> 1.) >> @@ -25,6 +33,10 @@ EXAMPLES: >> ipa ca-add puppet --desc "Puppet" \\ >> --subject "CN=Puppet CA,O=EXAMPLE.COM" >> >> + Disable a CA. >> + >> + ipa ca-disable puppet >> + >> """) >> >> You missed an example of `ca-enable` command in the doc string. >> >> 2.) >> >> Regarding implementation of ca_enable/disable, I think you can reduce >> the amount of code duplication by employing a base class which will look >> up the required sub-CA and call the RA backend method required by the >> subclass. See the attached untested diff (passes lint) for details. > > NACK, please don't use getattr() this way. Since you are subclassing > here, you should use polymorphism: > > class CAQuery(LDAPQuery): > def execute(...): > ... > self.perform_action(ca_api, ca_id) > ... > > def perform_action(self, ca_api, ca_id): > raise NotImplementedError() > > class ca_enable(CAQuery): > def perform_action(self, ca_api, ca_id): > ca_api.enable_ca(ca_id) > > Honza > Looks like I forgot how to OOP while on PTO :) Honza is right, of course, see the example code in the attached diff (again not tested, just a quick example). -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: better_example.patch Type: text/x-patch Size: 2245 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Aug 30 08:23:53 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 30 Aug 2016 10:23:53 +0200 Subject: [Freeipa-devel] [freeipa PR#25] Added install check before executing ipa-* command (comment) In-Reply-To: References: Message-ID: jcholast commented on a pull request """ @tomaskrizek: none of them except `ipa trust-find` fail with "cannot connect to 'http://localhost:8888/ipa/json'", so I would say only `ipa trust-find` needs to be fixed. """ See the full comment at https://github.com/freeipa/freeipa/pull/25#issuecomment-243368184 From freeipa-github-notification at redhat.com Tue Aug 30 08:24:52 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 30 Aug 2016 10:24:52 +0200 Subject: [Freeipa-devel] [freeipa PR#33] Update translations (+ack) In-Reply-To: References: Message-ID: mbasti-rh's pull request #33: "Update translations" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/33 From freeipa-github-notification at redhat.com Tue Aug 30 08:25:30 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Tue, 30 Aug 2016 10:25:30 +0200 Subject: [Freeipa-devel] [freeipa PR#30] Print to debug output answer from CA (comment) In-Reply-To: References: Message-ID: ofayans commented on a pull request """ QA ACK. It rocks: the debug output really helps identify the cause of CA-related errors. See for example [this issue](https://fedorahosted.org/freeipa/ticket/6274) """ See the full comment at https://github.com/freeipa/freeipa/pull/30#issuecomment-243368617 From freeipa-github-notification at redhat.com Tue Aug 30 08:26:10 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Tue, 30 Aug 2016 10:26:10 +0200 Subject: [Freeipa-devel] [freeipa PR#30] Print to debug output answer from CA (+ack) In-Reply-To: References: Message-ID: mbasti-rh's pull request #30: "Print to debug output answer from CA" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/30 From freeipa-github-notification at redhat.com Tue Aug 30 08:26:21 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 30 Aug 2016 10:26:21 +0200 Subject: [Freeipa-devel] [freeipa PR#33] Update translations (comment) In-Reply-To: References: Message-ID: martbab commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/cb1cee4db830e2eee4e72560958a3e4e4f5ca007 """ See the full comment at https://github.com/freeipa/freeipa/pull/33#issuecomment-243368823 From freeipa-github-notification at redhat.com Tue Aug 30 08:26:22 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 30 Aug 2016 10:26:22 +0200 Subject: [Freeipa-devel] [freeipa PR#33] Update translations (+pushed) In-Reply-To: References: Message-ID: mbasti-rh's pull request #33: "Update translations" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/33 From freeipa-github-notification at redhat.com Tue Aug 30 08:26:23 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 30 Aug 2016 10:26:23 +0200 Subject: [Freeipa-devel] [freeipa PR#33] Update translations (closed) In-Reply-To: References: Message-ID: mbasti-rh's pull request #33: "Update translations" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/33 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/33/head:pr33 git checkout pr33 From freeipa-github-notification at redhat.com Tue Aug 30 08:29:17 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 30 Aug 2016 10:29:17 +0200 Subject: [Freeipa-devel] [freeipa PR#32] Test for caacl-add-service (comment) In-Reply-To: References: Message-ID: tomaskrizek commented on a pull request """ Works as expected. """ See the full comment at https://github.com/freeipa/freeipa/pull/32#issuecomment-243369652 From freeipa-github-notification at redhat.com Tue Aug 30 08:29:21 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 30 Aug 2016 10:29:21 +0200 Subject: [Freeipa-devel] [freeipa PR#32] Test for caacl-add-service (+ack) In-Reply-To: References: Message-ID: gkaihorodova's pull request #32: "Test for caacl-add-service" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/32 From freeipa-github-notification at redhat.com Tue Aug 30 08:31:56 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 30 Aug 2016 10:31:56 +0200 Subject: [Freeipa-devel] [freeipa PR#36] Fix tests for forward zones (comment) In-Reply-To: References: Message-ID: stlaz commented on a pull request """ This seems to have fixed the test issue, ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/36#issuecomment-243370278 From freeipa-github-notification at redhat.com Tue Aug 30 08:32:00 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 30 Aug 2016 10:32:00 +0200 Subject: [Freeipa-devel] [freeipa PR#36] Fix tests for forward zones (+ack) In-Reply-To: References: Message-ID: pspacek's pull request #36: "Fix tests for forward zones" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/36 From jcholast at redhat.com Tue Aug 30 08:39:16 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 30 Aug 2016 10:39:16 +0200 Subject: [Freeipa-devel] [PATCH] 0106 Make host/service cert revocation aware of lightweight CAs In-Reply-To: <20160826054222.GQ3877@dhcp-40-8.bne.redhat.com> References: <20160826053717.GP3877@dhcp-40-8.bne.redhat.com> <20160826054222.GQ3877@dhcp-40-8.bne.redhat.com> Message-ID: Hi, On 26.8.2016 07:42, Fraser Tweedale wrote: > On Fri, Aug 26, 2016 at 03:37:17PM +1000, Fraser Tweedale wrote: >> Hi all, >> >> Attached patch fixes https://fedorahosted.org/freeipa/ticket/6221. >> It depends on Honza's PR #20 >> https://github.com/freeipa/freeipa/pull/20. >> >> Thanks, >> Fraser >> > It does help to attach the patch :) I think it would be better to call cert-find once per host-del/service-del with the --host/--service option specified. That way you'll get all certificates for the given host/service at once. Honza -- Jan Cholasta From freeipa-github-notification at redhat.com Tue Aug 30 08:36:34 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 10:36:34 +0200 Subject: [Freeipa-devel] [freeipa PR#32] Test for caacl-add-service (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/572bb55da4aedaae0cf529ab343484db06d89731 """ See the full comment at https://github.com/freeipa/freeipa/pull/32#issuecomment-243371317 From freeipa-github-notification at redhat.com Tue Aug 30 08:36:35 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 10:36:35 +0200 Subject: [Freeipa-devel] [freeipa PR#32] Test for caacl-add-service (+pushed) In-Reply-To: References: Message-ID: gkaihorodova's pull request #32: "Test for caacl-add-service" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/32 From freeipa-github-notification at redhat.com Tue Aug 30 08:36:36 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 10:36:36 +0200 Subject: [Freeipa-devel] [freeipa PR#32] Test for caacl-add-service (closed) In-Reply-To: References: Message-ID: gkaihorodova's pull request #32: "Test for caacl-add-service" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/32 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/32/head:pr32 git checkout pr32 From freeipa-github-notification at redhat.com Tue Aug 30 08:40:31 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 10:40:31 +0200 Subject: [Freeipa-devel] [freeipa PR#36] Fix tests for forward zones (+pushed) In-Reply-To: References: Message-ID: pspacek's pull request #36: "Fix tests for forward zones" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/36 From freeipa-github-notification at redhat.com Tue Aug 30 08:40:32 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 10:40:32 +0200 Subject: [Freeipa-devel] [freeipa PR#36] Fix tests for forward zones (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/8f1ba05c26921fb787c3eb1bb846a13e06e424ff """ See the full comment at https://github.com/freeipa/freeipa/pull/36#issuecomment-243372212 From freeipa-github-notification at redhat.com Tue Aug 30 08:40:33 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 10:40:33 +0200 Subject: [Freeipa-devel] [freeipa PR#36] Fix tests for forward zones (closed) In-Reply-To: References: Message-ID: pspacek's pull request #36: "Fix tests for forward zones" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/36 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/36/head:pr36 git checkout pr36 From freeipa-github-notification at redhat.com Tue Aug 30 08:48:22 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 10:48:22 +0200 Subject: [Freeipa-devel] [freeipa PR#36] Fix tests for forward zones (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ master: eabe248957f75a1dd3b8d3d330740d929f9e42d9 Only one patch was pushed, there was error found in tooling """ See the full comment at https://github.com/freeipa/freeipa/pull/36#issuecomment-243374067 From mbasti at redhat.com Tue Aug 30 08:50:23 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 30 Aug 2016 10:50:23 +0200 Subject: [Freeipa-devel] [PATCH 0159] Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin In-Reply-To: References: Message-ID: On 16.08.2016 13:55, Martin Basti wrote: > > > > On 16.08.2016 13:30, Martin Basti wrote: >> >> >> >> On 12.08.2016 20:00, Petr Spacek wrote: >>> Hello, >>> >>> this is the last patch necessary to get all test_xmlrpc/test_dns_plugin tests >>> to pass! (I hope :-) >>> >>> Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin >>> >>> Class test_forward_zones in ipatests/test_xmlrpc/test_dns_plugin >>> was using DNS zone 'fwzone2.test.' and expected to get warning >>> 'Forwarding policy conflicts with some automatic empty zones.' >>> (aka 'DNSForwardPolicyConflictWithEmptyZone'). >>> >>> This does not make sense because 'test.' zone is not listed in IANA registry >>> 'Locally-Served DNS Zones': >>> >>> http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml >>> >>> To fix this I simply removed the warning from set of expected results. >>> >>> https://fedorahosted.org/freeipa/ticket/6213 >>> >>> >>> >>> >> >> NACK >> >> raise AssertionError( >> > VALUE % (doc, expected, got, stack) >> E AssertionError: assert_deepequal: expected != got. >> E 0014: dnsforwardzone_add: Create forward zone >> u'fwzone2.test.' with forwarders with default ("first") policy >> E expected = at 0x7f76f1225500> >> E got = u"query 'fwzone2.test. SOA': The DNS >> operation timed out after 10.0012469292 seconds" >> E path = (u'messages', 0, u'data', u'error') >> >> >> I don't think that this will work, you must use function to check >> list, not list containing lambda functions >> >> >> Martin^2 >> >> > > Sorry, my bad, it is just wrong expected message in lambda > > This was resolved in: https://github.com/freeipa/freeipa/pull/36 Please don't mix PR and patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Tue Aug 30 08:51:58 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 30 Aug 2016 10:51:58 +0200 Subject: [Freeipa-devel] [freeipa PR#25] Added install check before executing ipa-* command (comment) In-Reply-To: References: Message-ID: pspacek commented on a pull request """ All this is consequence of nonsensical defaults in ipalib.constants module. I would say that this needs to be fixed in a systematic way and not by scattering ifs around. IMHO we need to drop nonsensical defaults form ipalib.constants module and handle missing values in API initialization. We should throw out exception if API cannot be initialized because of missing values (and/or failing auto-detection, depending on parameters in constructor) instead of scattering ifs around. For example: Right now the only way to trigger server auto-selection using DNS SRV record is to delete server= definition from default.conf. Of course, it is broken and it tries localhost first and fallbacks to auto-detected server after that, but it works somehow. If we scatter ifs around it will break in some other interesting way. I'm still waiting for branching ipa-4-4. After that I can send my patch which removes some of crazy defaults from ipalib.constants. """ See the full comment at https://github.com/freeipa/freeipa/pull/25#issuecomment-243374973 From freeipa-github-notification at redhat.com Tue Aug 30 08:54:26 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 10:54:26 +0200 Subject: [Freeipa-devel] [freeipa PR#30] Print to debug output answer from CA (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/5251cf5d14ffc178ead6e0af053d391f5b7a6782 """ See the full comment at https://github.com/freeipa/freeipa/pull/30#issuecomment-243375582 From freeipa-github-notification at redhat.com Tue Aug 30 08:54:29 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 10:54:29 +0200 Subject: [Freeipa-devel] [freeipa PR#30] Print to debug output answer from CA (+pushed) In-Reply-To: References: Message-ID: mbasti-rh's pull request #30: "Print to debug output answer from CA" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/30 From freeipa-github-notification at redhat.com Tue Aug 30 08:54:30 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 10:54:30 +0200 Subject: [Freeipa-devel] [freeipa PR#30] Print to debug output answer from CA (closed) In-Reply-To: References: Message-ID: mbasti-rh's pull request #30: "Print to debug output answer from CA" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/30 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/30/head:pr30 git checkout pr30 From mbabinsk at redhat.com Tue Aug 30 08:54:32 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 30 Aug 2016 10:54:32 +0200 Subject: [Freeipa-devel] [PATCH] 0102..0105 Better handling for cert-request to disabled CA In-Reply-To: <20160826021907.GN3877@dhcp-40-8.bne.redhat.com> References: <20160826021907.GN3877@dhcp-40-8.bne.redhat.com> Message-ID: On 08/26/2016 04:19 AM, Fraser Tweedale wrote: > The attached patches add better handling of cert-request failure due > to target CA being disabled (#6260). To do this, rather than go and > do extra work in Dogtag that we would depend on, instead I bite the > bullet and refactor ra.request_certificate to use the Dogtag REST > API, which correctly responds with status 409 in this case. > > Switching RA to Dogtag REST API is an old ticket (#3437) so these > patches address it in part, and show the way forward for the rest of > it. > > These patches don't technically depend on patch 0101 which adds the > ca-enable and ca-disable commands, but 0101 may help for testing :) > > Thanks, > Fraser > > > Hi Fraser, PATCH 102: LGTM, but please use the standard ":param " annotations in the docstring for `_ssldo` method. It will make out life easier if we decide to use Sphinx or similar tool to auto-generate documentation from sources. You can also add ":raises:" section describing that RemoteRetrieveError is raised when use_session is True but the session cookie wasn't acquired. It is kind of obvious but it may trip the uninitiated. PATCH 103: Due to magical behavior of our public errors, the exception body should look like this: --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -1413,10 +1413,7 @@ class HTTPRequestError(RemoteRetrieveError): """ errno = 4035 - - def __init__(self, status=None, **kw): - assert status is not None - super(HTTPRequestError, self).__init__(status=status, **kw) + format = _('Request failed with status %(status)s: %(reason)') The format string will be then automatically be supplied with status and reason if you pass them to the constructor ass you already do. The errors will be also handled magically (such as status which is None etc.) PATCH 104: 1.) please don't use bare except here: """ + try: + resp_obj = json.loads(http_body) + except: + raise errors.RemoteRetrieveError(reason=_("Response from CA was not valid JSON")) """ use 'except Exception' at least. PATCH 105: + if e.status == 409: # pylint: disable=E1101 + raise errors.CertificateOperationError( + error=_("CA '%s' is disabled") % ca) + else: + raise e + please use named errors instead of error codes in pylint annotations: # pylint: disable=no-member -- Martin^3 Babinsky From ofayans at redhat.com Tue Aug 30 09:36:15 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 30 Aug 2016 11:36:15 +0200 Subject: [Freeipa-devel] [Test][patch-0061] Fixed error in teardown method of replica_promotion tests In-Reply-To: <48021659-0f1e-bd9a-3196-799104ecab80@redhat.com> References: <48021659-0f1e-bd9a-3196-799104ecab80@redhat.com> Message-ID: Bump for review. Other tests depend on this fix too, like replication_layouts_domainlevel_1 On 08/24/2016 04:26 PM, Oleg Fayans wrote: > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From freeipa-github-notification at redhat.com Tue Aug 30 09:47:56 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Tue, 30 Aug 2016 11:47:56 +0200 Subject: [Freeipa-devel] [freeipa PR#38] Removed incorrect check for returncode (opened) In-Reply-To: References: Message-ID: ofayans's pull request #38: "Removed incorrect check for returncode" was opened PR body: """ The server installation in most cases returns response code 0 no matter what happens except for really severe errors. In this case when we try to uninstall the middle replica of a line topology, it fails, notifies us that we should use '--ignore-topology-disconnect', but returns 0 https://fedorahosted.org/freeipa/ticket/3230 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/38 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/38/head:pr38 git checkout pr38 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-38.patch URL: From slaznick at redhat.com Tue Aug 30 09:51:38 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Tue, 30 Aug 2016 11:51:38 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: References: <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1a254cbc-120f-1645-6a4e-20ef5563719f@redhat.com> <22d981eb-b51a-4325-ee93-d0023aa5ead8@redhat.com> <20160830072317.dz6ugrwdxgb3qtna@redhat.com> Message-ID: <884658ac-5709-f133-7142-b1208d7a6bf1@redhat.com> On 08/30/2016 09:34 AM, Standa Laznicka wrote: > On 08/30/2016 09:23 AM, Alexander Bokovoy wrote: >> On Tue, 30 Aug 2016, Jan Cholasta wrote: >>> On 30.8.2016 08:47, Standa Laznicka wrote: >>>> On 08/26/2016 05:37 PM, Simo Sorce wrote: >>>>> On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: >>>>>> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: >>>>>>> On Fri, 26 Aug 2016, Simo Sorce wrote: >>>>>>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: >>>>>>>>>> I miss "why" part of "To be able to handle backward >>>>>>>>>> compatibility >>>>>>>>> with >>>>>>>>>> ease, a new object called ipaHBACRulev2 is introduced. " in the >>>>>>>>> design >>>>>>>>>> page. If the reason is the above - old client's should ignore >>>>>>>>>> time >>>>>>>>> rules >>>>>>>>>> then it has to be mentioned there. Otherwise I don't see a >>>>>>>>>> reason to >>>>>>>>>> introduce a new object type instead of extending the current. >>>>>>>>> How do you want to enforce HBAC rule that have set time from >>>>>>>>> 10 to 14 >>>>>>>>> everyday? With the same objectclass old clients will allow >>>>>>>>> this HBAC >>>>>>>>> for >>>>>>>>> all day. Isn't this CVE? >>>>>>>> This is a discussion worth having. >>>>>>>> >>>>>>>> In general it is a CVE only if an authorization mechanism fails to >>>>>>>> work >>>>>>>> as advertised. >>>>>>>> >>>>>>>> If you make it clear that old clients *DO NOT* respect time >>>>>>>> rules then >>>>>>>> there is no CVE material, it is working as "described". >>>>>>>> >>>>>>>> The admins already have a way to not set those rules for older >>>>>>>> clients >>>>>>>> by simply grouping newer clients in a different host group and >>>>>>>> applying >>>>>>>> time rules only there. >>>>>>>> >>>>>>>> So the question really is: should we allow admins to apply an HBAC >>>>>>>> Rule >>>>>>>> potentially to older clients that do not understand it and will >>>>>>>> therefore allow access at any time of the day, or should we >>>>>>>> prevent >>>>>>>> it ? >>>>>>>> >>>>>>>> This is a hard question to answer and can go both ways. >>>>>>>> >>>>>>>> A time rule may be something that admins want to enforce at all >>>>>>>> cost or >>>>>>>> deny access. In this case a client that fails to handle it >>>>>>>> would be a >>>>>>>> problem. >>>>>>>> >>>>>>>> But it may be something that is just used for defense in depth and >>>>>>>> not a >>>>>>>> strictly hard requirement. In this case allowing older clients >>>>>>>> would >>>>>>>> make it an easy transition as you just set up the rule and the >>>>>>>> client >>>>>>>> will start enforcing the time when it is upgraded but work >>>>>>>> otherwise >>>>>>>> with the same rules. >>>>>>>> >>>>>>>> I am a bit conflicted on trying to decide what scenario we should >>>>>>>> target, but the second one appeals to me because host groups do >>>>>>>> already >>>>>>>> give admins a good way to apply rules to a specific set of >>>>>>>> hosts and >>>>>>>> exclude old clients w/o us making it a hard rule. >>>>>>>> OTOH if an admin does not understand this difference, they may be >>>>>>>> surprised to find out there are clients that do not honor it. >>>>>>>> >>>>>>>> Perhaps we could find a way to set a flag on the rule such that >>>>>>>> when set >>>>>>>> (and only when set) older clients get excluded by way of >>>>>>>> changing the >>>>>>>> objectlass or something else to similar effect. >>>>>>>> >>>>>>>> Open to discussion. >>>>>>> At this point using new object class becomes an attractive >>>>>>> approach. We >>>>>>> don't have means to exclude HBAC rules other than applying them >>>>>>> per-host/hostgroup. We also have no deny rules. >>>>>>> >>>>>>> I have another idea: what about enforcing time rules always to >>>>>>> apply >>>>>>> per-host or per-hostgroup by default? Add --force option to >>>>>>> override >>>>>>> the >>>>>>> behavior but default to not allow --hostcat=all. This would raise >>>>>>> awareness and make sure admins are actually applying these rules >>>>>>> with >>>>>>> intention. >>>>>> This sounds like a good idea, but it is not a silver bullet I am >>>>>> afraid. >>>>>> >>>>>> Simo. >>>>> I was thinking that for future proofing we could add a version field, >>>>> then reasoned more and realized that changing the object class is >>>>> basically the same thing. >>>>> >>>>> There is only one big problem, ipaHBACRule is a STRUCTURAL >>>>> objectclass. >>>>> (I know 389ds allows us to do an LDAPv3 illegal operation and >>>>> change it, >>>>> but I do not like to depend on that behavoir). >>>>> >>>>> Now looking into this I had an idea to solve the problem of legacy >>>>> clients without having to swap classes. >>>>> We can redefine the accessRuleType attribute to be a "capability" >>>>> type. >>>>> >>>>> Ie rules that have a timeAccess component will be of type >>>>> "allow_with_time" instead of just "allow". >>>>> Old clients are supposed to search with accessRuleType=allow (and >>>>> I can >>>>> see that SSSD does that), so an older client will fail to get those >>>>> rules as they won't match. >>>>> >>>>> New clients instead can recognize both types. >>>>> >>>>> Also if we need a future extension we will simpy add a new access >>>>> rule >>>>> type and we can have the same effect. >>>>> The nice thing is that accessRyleType is defined as multivalue (no >>>>> SINGLE in schema) so we may actually create compatible rules if we >>>>> want >>>>> to. >>>>> Ie we could set both "allow" and "allow_with_time" on an object for >>>>> cases where the admin wants to enforce the time part only o newer >>>>> client >>>>> but otherwise apply the rule to any client. >>>>> >>>>> This should give us the best of all options at once. >>>>> >>>>> Thoughts ? >>>>> >>>>> Simo. >>>>> >>>> Sorry to join the discussion so late, I was away yesterday. >>>> >>>> I have to say I too like this idea much better than fiddling with the >>>> objectClasses. >>> >>> Note that the resulting code will be exactly the same except for the >>> attribute name - you won't be fiddling with objectClass but with >>> attributeRuleType. > I do realize that (even though I touched this in my first question) > but this solution seems a bit cleaner to me. >>> >>>> Also, I believe that accessRuleType was originally >>>> actually used to distinguish newer version of HBAC rules from the >>>> older >>>> so we may just do this again and profit from its original purpose. >>> >>> The original purpose was to support deny rules, but they were >>> deprecated. >>> >>>> To >>>> top it off, this change should be really easy to implement to what I >>>> currently have on SSSD side. >>>> >>>> I was just wondering - would you propose for every newly created >>>> rule to >>>> have the new accessRuleType set to "allow_with_time" or should the >>>> type >>>> change with addition of time rules to the HBAC rule as it does >>>> currently? Also, should the user be able to modify the type so that a >>>> rule with the new type is also visible for older clients (=> he could >>>> add "allow" to type anytime)? >>>> >>>> Thanks for your ideas, I am very happy with what you suggested here :) >>> >>> TBH I'm not - I don't find adding hacks on top of obsolete >>> deprecated stuff to be a particularly appealing solution to anything. >> It is just an attribute. Reusing an attribute that is not used anymore >> for anything else is not a bad thing. The original solution may be >> deprecated but the schema is in place and will be almost forever, so >> using otherwise unused but present schema is just fine. >> > +1, why not to use it if there's no other use for it anyway. > Actually, I gave it a further thought - the problem with using accessRuleType for this purpose would be that even the new rules that older clients can't evaluate correctly would be displayed/listed in WebUI/hbacrule-find results. I do not think this should happen, it is confusing. I should also say explicitly that I do NOT think that if a time rule is set for an HBAC rule this HBAC rule should still be taken into account during evaluation on an old client. To base the decision whether to allow/not-allow access purely on a client version is just wrong. From freeipa-github-notification at redhat.com Tue Aug 30 09:53:24 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Tue, 30 Aug 2016 11:53:24 +0200 Subject: [Freeipa-devel] [freeipa PR#38] Removed incorrect check for returncode (synchronize) In-Reply-To: References: Message-ID: ofayans's pull request #38: "Removed incorrect check for returncode" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/38 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/38/head:pr38 git checkout pr38 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-38.patch URL: From mbasti at redhat.com Tue Aug 30 09:59:51 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 30 Aug 2016 11:59:51 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <884658ac-5709-f133-7142-b1208d7a6bf1@redhat.com> References: <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1a254cbc-120f-1645-6a4e-20ef5563719f@redhat.com> <22d981eb-b51a-4325-ee93-d0023aa5ead8@redhat.com> <20160830072317.dz6ugrwdxgb3qtna@redhat.com> <884658ac-5709-f133-7142-b1208d7a6bf1@redhat.com> Message-ID: On 30.08.2016 11:51, Standa Laznicka wrote: > On 08/30/2016 09:34 AM, Standa Laznicka wrote: >> On 08/30/2016 09:23 AM, Alexander Bokovoy wrote: >>> On Tue, 30 Aug 2016, Jan Cholasta wrote: >>>> On 30.8.2016 08:47, Standa Laznicka wrote: >>>>> On 08/26/2016 05:37 PM, Simo Sorce wrote: >>>>>> On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: >>>>>>> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: >>>>>>>> On Fri, 26 Aug 2016, Simo Sorce wrote: >>>>>>>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: >>>>>>>>>>> I miss "why" part of "To be able to handle backward >>>>>>>>>>> compatibility >>>>>>>>>> with >>>>>>>>>>> ease, a new object called ipaHBACRulev2 is introduced. " in the >>>>>>>>>> design >>>>>>>>>>> page. If the reason is the above - old client's should >>>>>>>>>>> ignore time >>>>>>>>>> rules >>>>>>>>>>> then it has to be mentioned there. Otherwise I don't see a >>>>>>>>>>> reason to >>>>>>>>>>> introduce a new object type instead of extending the current. >>>>>>>>>> How do you want to enforce HBAC rule that have set time from >>>>>>>>>> 10 to 14 >>>>>>>>>> everyday? With the same objectclass old clients will allow >>>>>>>>>> this HBAC >>>>>>>>>> for >>>>>>>>>> all day. Isn't this CVE? >>>>>>>>> This is a discussion worth having. >>>>>>>>> >>>>>>>>> In general it is a CVE only if an authorization mechanism >>>>>>>>> fails to >>>>>>>>> work >>>>>>>>> as advertised. >>>>>>>>> >>>>>>>>> If you make it clear that old clients *DO NOT* respect time >>>>>>>>> rules then >>>>>>>>> there is no CVE material, it is working as "described". >>>>>>>>> >>>>>>>>> The admins already have a way to not set those rules for older >>>>>>>>> clients >>>>>>>>> by simply grouping newer clients in a different host group and >>>>>>>>> applying >>>>>>>>> time rules only there. >>>>>>>>> >>>>>>>>> So the question really is: should we allow admins to apply an >>>>>>>>> HBAC >>>>>>>>> Rule >>>>>>>>> potentially to older clients that do not understand it and will >>>>>>>>> therefore allow access at any time of the day, or should we >>>>>>>>> prevent >>>>>>>>> it ? >>>>>>>>> >>>>>>>>> This is a hard question to answer and can go both ways. >>>>>>>>> >>>>>>>>> A time rule may be something that admins want to enforce at all >>>>>>>>> cost or >>>>>>>>> deny access. In this case a client that fails to handle it >>>>>>>>> would be a >>>>>>>>> problem. >>>>>>>>> >>>>>>>>> But it may be something that is just used for defense in depth >>>>>>>>> and >>>>>>>>> not a >>>>>>>>> strictly hard requirement. In this case allowing older clients >>>>>>>>> would >>>>>>>>> make it an easy transition as you just set up the rule and the >>>>>>>>> client >>>>>>>>> will start enforcing the time when it is upgraded but work >>>>>>>>> otherwise >>>>>>>>> with the same rules. >>>>>>>>> >>>>>>>>> I am a bit conflicted on trying to decide what scenario we should >>>>>>>>> target, but the second one appeals to me because host groups do >>>>>>>>> already >>>>>>>>> give admins a good way to apply rules to a specific set of >>>>>>>>> hosts and >>>>>>>>> exclude old clients w/o us making it a hard rule. >>>>>>>>> OTOH if an admin does not understand this difference, they may be >>>>>>>>> surprised to find out there are clients that do not honor it. >>>>>>>>> >>>>>>>>> Perhaps we could find a way to set a flag on the rule such that >>>>>>>>> when set >>>>>>>>> (and only when set) older clients get excluded by way of >>>>>>>>> changing the >>>>>>>>> objectlass or something else to similar effect. >>>>>>>>> >>>>>>>>> Open to discussion. >>>>>>>> At this point using new object class becomes an attractive >>>>>>>> approach. We >>>>>>>> don't have means to exclude HBAC rules other than applying them >>>>>>>> per-host/hostgroup. We also have no deny rules. >>>>>>>> >>>>>>>> I have another idea: what about enforcing time rules always to >>>>>>>> apply >>>>>>>> per-host or per-hostgroup by default? Add --force option to >>>>>>>> override >>>>>>>> the >>>>>>>> behavior but default to not allow --hostcat=all. This would raise >>>>>>>> awareness and make sure admins are actually applying these >>>>>>>> rules with >>>>>>>> intention. >>>>>>> This sounds like a good idea, but it is not a silver bullet I am >>>>>>> afraid. >>>>>>> >>>>>>> Simo. >>>>>> I was thinking that for future proofing we could add a version >>>>>> field, >>>>>> then reasoned more and realized that changing the object class is >>>>>> basically the same thing. >>>>>> >>>>>> There is only one big problem, ipaHBACRule is a STRUCTURAL >>>>>> objectclass. >>>>>> (I know 389ds allows us to do an LDAPv3 illegal operation and >>>>>> change it, >>>>>> but I do not like to depend on that behavoir). >>>>>> >>>>>> Now looking into this I had an idea to solve the problem of legacy >>>>>> clients without having to swap classes. >>>>>> We can redefine the accessRuleType attribute to be a "capability" >>>>>> type. >>>>>> >>>>>> Ie rules that have a timeAccess component will be of type >>>>>> "allow_with_time" instead of just "allow". >>>>>> Old clients are supposed to search with accessRuleType=allow (and >>>>>> I can >>>>>> see that SSSD does that), so an older client will fail to get those >>>>>> rules as they won't match. >>>>>> >>>>>> New clients instead can recognize both types. >>>>>> >>>>>> Also if we need a future extension we will simpy add a new access >>>>>> rule >>>>>> type and we can have the same effect. >>>>>> The nice thing is that accessRyleType is defined as multivalue (no >>>>>> SINGLE in schema) so we may actually create compatible rules if >>>>>> we want >>>>>> to. >>>>>> Ie we could set both "allow" and "allow_with_time" on an object for >>>>>> cases where the admin wants to enforce the time part only o newer >>>>>> client >>>>>> but otherwise apply the rule to any client. >>>>>> >>>>>> This should give us the best of all options at once. >>>>>> >>>>>> Thoughts ? >>>>>> >>>>>> Simo. >>>>>> >>>>> Sorry to join the discussion so late, I was away yesterday. >>>>> >>>>> I have to say I too like this idea much better than fiddling with the >>>>> objectClasses. >>>> >>>> Note that the resulting code will be exactly the same except for >>>> the attribute name - you won't be fiddling with objectClass but >>>> with attributeRuleType. >> I do realize that (even though I touched this in my first question) >> but this solution seems a bit cleaner to me. >>>> >>>>> Also, I believe that accessRuleType was originally >>>>> actually used to distinguish newer version of HBAC rules from the >>>>> older >>>>> so we may just do this again and profit from its original purpose. >>>> >>>> The original purpose was to support deny rules, but they were >>>> deprecated. >>>> >>>>> To >>>>> top it off, this change should be really easy to implement to what I >>>>> currently have on SSSD side. >>>>> >>>>> I was just wondering - would you propose for every newly created >>>>> rule to >>>>> have the new accessRuleType set to "allow_with_time" or should the >>>>> type >>>>> change with addition of time rules to the HBAC rule as it does >>>>> currently? Also, should the user be able to modify the type so that a >>>>> rule with the new type is also visible for older clients (=> he could >>>>> add "allow" to type anytime)? >>>>> >>>>> Thanks for your ideas, I am very happy with what you suggested >>>>> here :) >>>> >>>> TBH I'm not - I don't find adding hacks on top of obsolete >>>> deprecated stuff to be a particularly appealing solution to anything. >>> It is just an attribute. Reusing an attribute that is not used anymore >>> for anything else is not a bad thing. The original solution may be >>> deprecated but the schema is in place and will be almost forever, so >>> using otherwise unused but present schema is just fine. >>> >> +1, why not to use it if there's no other use for it anyway. >> > Actually, I gave it a further thought - the problem with using > accessRuleType for this purpose would be that even the new rules that > older clients can't evaluate correctly would be displayed/listed in > WebUI/hbacrule-find results. I do not think this should happen, it is > confusing. > > I should also say explicitly that I do NOT think that if a time rule > is set for an HBAC rule this HBAC rule should still be taken into > account during evaluation on an old client. To base the decision > whether to allow/not-allow access purely on a client version is just > wrong. > I agree, we should not mix this on old clients, I like the most the original proposal with switching objeclasses Martin^2 From freeipa-github-notification at redhat.com Tue Aug 30 10:02:59 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 12:02:59 +0200 Subject: [Freeipa-devel] [freeipa PR#37] cert: add missing param values to cert-find output (+pushed) In-Reply-To: References: Message-ID: jcholast's pull request #37: "cert: add missing param values to cert-find output" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/37 From freeipa-github-notification at redhat.com Tue Aug 30 10:03:01 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 12:03:01 +0200 Subject: [Freeipa-devel] [freeipa PR#37] cert: add missing param values to cert-find output (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/22d5f579bbd8bb452cf1bf620294ab6ade6e7c47 """ See the full comment at https://github.com/freeipa/freeipa/pull/37#issuecomment-243392998 From freeipa-github-notification at redhat.com Tue Aug 30 10:31:51 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 12:31:51 +0200 Subject: [Freeipa-devel] [freeipa PR#20] cert: include CA name in cert command output (+ack) In-Reply-To: References: Message-ID: jcholast's pull request #20: "cert: include CA name in cert command output" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/20 From freeipa-github-notification at redhat.com Tue Aug 30 10:38:45 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 30 Aug 2016 12:38:45 +0200 Subject: [Freeipa-devel] [freeipa PR#20] cert: include CA name in cert command output (synchronize) In-Reply-To: References: Message-ID: jcholast's pull request #20: "cert: include CA name in cert command output" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/20 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/20/head:pr20 git checkout pr20 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-20.patch URL: From freeipa-github-notification at redhat.com Tue Aug 30 10:39:19 2016 From: freeipa-github-notification at redhat.com (apophys) Date: Tue, 30 Aug 2016 12:39:19 +0200 Subject: [Freeipa-devel] [freeipa PR#38] Removed incorrect check for returncode (comment) In-Reply-To: References: Message-ID: apophys commented on a pull request """ Can you please rewrite the commit message in second commit to something meaningful? """ See the full comment at https://github.com/freeipa/freeipa/pull/38#issuecomment-243400759 From freeipa-github-notification at redhat.com Tue Aug 30 10:42:39 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 12:42:39 +0200 Subject: [Freeipa-devel] [freeipa PR#20] cert: include CA name in cert command output (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/117274ff047eb4148fd2624ae800f45e50a7e2cd """ See the full comment at https://github.com/freeipa/freeipa/pull/20#issuecomment-243401428 From freeipa-github-notification at redhat.com Tue Aug 30 10:42:40 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 12:42:40 +0200 Subject: [Freeipa-devel] [freeipa PR#20] cert: include CA name in cert command output (+pushed) In-Reply-To: References: Message-ID: jcholast's pull request #20: "cert: include CA name in cert command output" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/20 From freeipa-github-notification at redhat.com Tue Aug 30 10:42:41 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 12:42:41 +0200 Subject: [Freeipa-devel] [freeipa PR#20] cert: include CA name in cert command output (closed) In-Reply-To: References: Message-ID: jcholast's pull request #20: "cert: include CA name in cert command output" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/20 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/20/head:pr20 git checkout pr20 From freeipa-github-notification at redhat.com Tue Aug 30 10:56:33 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Tue, 30 Aug 2016 12:56:33 +0200 Subject: [Freeipa-devel] [freeipa PR#39] Tests: Add missing attributes to test_xmlrpc/test_trust tests (opened) In-Reply-To: References: Message-ID: mirielka's pull request #39: "Tests: Add missing attributes to test_xmlrpc/test_trust tests" was opened PR body: """ Several tests in test_xmlrpc/test_trust_plugin.py fail because some attributes are not expected. Fixing the tests so that the extra attributes are recognized. https://fedorahosted.org/freeipa/ticket/6276 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/39 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/39/head:pr39 git checkout pr39 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-39.patch URL: From freeipa-github-notification at redhat.com Tue Aug 30 11:10:57 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Tue, 30 Aug 2016 13:10:57 +0200 Subject: [Freeipa-devel] [freeipa PR#38] Removed incorrect check for returncode (synchronize) In-Reply-To: References: Message-ID: ofayans's pull request #38: "Removed incorrect check for returncode" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/38 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/38/head:pr38 git checkout pr38 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-38.patch URL: From freeipa-github-notification at redhat.com Tue Aug 30 11:13:16 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Tue, 30 Aug 2016 13:13:16 +0200 Subject: [Freeipa-devel] [freeipa PR#38] Removed incorrect check for returncode (synchronize) In-Reply-To: References: Message-ID: ofayans's pull request #38: "Removed incorrect check for returncode" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/38 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/38/head:pr38 git checkout pr38 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-pr-38.patch URL: From freeipa-github-notification at redhat.com Tue Aug 30 11:13:44 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Tue, 30 Aug 2016 13:13:44 +0200 Subject: [Freeipa-devel] [freeipa PR#38] Removed incorrect check for returncode (comment) In-Reply-To: References: Message-ID: ofayans commented on a pull request """ Done. """ See the full comment at https://github.com/freeipa/freeipa/pull/38#issuecomment-243407459 From mbasti at redhat.com Tue Aug 30 11:14:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 30 Aug 2016 13:14:08 +0200 Subject: [Freeipa-devel] [Test][patch-0061] Fixed error in teardown method of replica_promotion tests In-Reply-To: <48021659-0f1e-bd9a-3196-799104ecab80@redhat.com> References: <48021659-0f1e-bd9a-3196-799104ecab80@redhat.com> Message-ID: <18464677-f9c2-1523-1f4a-eca5f23bed64@redhat.com> On 24.08.2016 16:26, Oleg Fayans wrote: > > > ACK Pushed to master: 5812af84a4a12528e969f14017e9675160b3faef -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Tue Aug 30 11:18:41 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 30 Aug 2016 13:18:41 +0200 Subject: [Freeipa-devel] [freeipa PR#24] [master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name (comment) In-Reply-To: References: Message-ID: tomaskrizek commented on a pull request """ Works as described. """ See the full comment at https://github.com/freeipa/freeipa/pull/24#issuecomment-243408470 From freeipa-github-notification at redhat.com Tue Aug 30 11:18:46 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 30 Aug 2016 13:18:46 +0200 Subject: [Freeipa-devel] [freeipa PR#24] [master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name (+ack) In-Reply-To: References: Message-ID: mirielka's pull request #24: "[master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/24 From freeipa-github-notification at redhat.com Tue Aug 30 11:22:17 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 13:22:17 +0200 Subject: [Freeipa-devel] [freeipa PR#24] [master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/2c7b7b3acc0a7131ea14cc43acb571150b585171 ipa-4-3: https://fedorahosted.org/freeipa/changeset/6064b122f995ca5e8f9bfcc72a8565d1280f8876 """ See the full comment at https://github.com/freeipa/freeipa/pull/24#issuecomment-243409176 From freeipa-github-notification at redhat.com Tue Aug 30 11:22:18 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 13:22:18 +0200 Subject: [Freeipa-devel] [freeipa PR#24] [master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name (closed) In-Reply-To: References: Message-ID: mirielka's pull request #24: "[master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/24 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/24/head:pr24 git checkout pr24 From freeipa-github-notification at redhat.com Tue Aug 30 11:22:19 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 13:22:19 +0200 Subject: [Freeipa-devel] [freeipa PR#24] [master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name (+pushed) In-Reply-To: References: Message-ID: mirielka's pull request #24: "[master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/24 From mbasti at redhat.com Tue Aug 30 11:27:43 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 30 Aug 2016 13:27:43 +0200 Subject: [Freeipa-devel] [PATCH] 0024 memory leak in ipapwd plugin In-Reply-To: <20160811143903.id66th5o63vhkpqi@redhat.com> References: <57AACBB9.1050608@redhat.com> <20160810092441.wmgv6jtrrej7bbxi@redhat.com> <57AB55A3.6040305@redhat.com> <20160810171927.fzjktnorevhlv46e@redhat.com> <57AC8407.70806@redhat.com> <20160811143903.id66th5o63vhkpqi@redhat.com> Message-ID: <11333e12-f5f7-4f5c-df4f-960447ad5c0d@redhat.com> On 11.08.2016 16:39, Alexander Bokovoy wrote: > On Thu, 11 Aug 2016, thierry bordaz wrote: >>>> + /* rc should always be 0 (else slapi_sdn_new_dn_byref >>>> should have sigsev) >>>> + * but if we end in rc==LDAP_OPERATIONS_ERROR be sure to >>>> stop here >>>> + * because ret is not significant */ >>> A short note here. You talk about slapi_sdn_new_dn_byref() but your >>> patch replaces that with slapi_sdn_new_dn_byval(). Does the comment >>> still apply? >>> >>>> + if (rc != 0) { >>>> + LOG_OOM(); >>>> + goto free_and_return; >>>> + } >>>> + >>>> if (ret == 0) { >>>> Slapi_Value *cpw[2] = { NULL, NULL }; >>>> Slapi_Value *pw; >>>> -- >>>> 2.7.4 >>>> >>> >>> >> Good catch Alexander. Yes the comment contained a wrong cut/paste > ACK. > > Is there a ticket for this? From mbasti at redhat.com Tue Aug 30 11:58:56 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 30 Aug 2016 13:58:56 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: References: <57723947.2090508@redhat.com> <5772622C.9000205@redhat.com> <579FB51F.6030808@redhat.com> <98a90ec8-fa79-dd36-57dc-053204c29506@redhat.com> <57A07FE4.8000904@redhat.com> Message-ID: On 22.08.2016 13:18, Oleg Fayans wrote: > ping for review > > On 08/02/2016 01:11 PM, Oleg Fayans wrote: >> Hi Martin, >> >> I did! Thank you! >> >> On 08/02/2016 12:31 PM, Martin Basti wrote: >>> >>> >>> On 01.08.2016 22:46, Oleg Fayans wrote: >>>> The test was redesigned so that it actually tests against an AD user. >>>> cleanly applies, passes lint and passes >>>> >>>> https://paste.fedoraproject.org/399504/00843641/ >>> >>> Okay >>> >>> Did you forget to send patches? >>> >>> Martin^2 >>>> >>>> >>>> On 06/28/2016 01:40 PM, Oleg Fayans wrote: >>>>> Patch-0050 rebased against latest upstream branch >>>>> >>>>> On 06/28/2016 10:45 AM, Oleg Fayans wrote: >>>>>> Passing test output: >>>>>> >>>>>> https://paste.fedoraproject.org/385774/71035231/ >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> >> > NACK for 0049.1 1) PEP8: you must use 2 empty lines between functions 2) + new_args = " ".join(new_args + args) you don't need this, run_command takes list as argument too new_args.extend(args) 3) To make it more usable you should add raiseonerr as kwarg to run_certutil (True as default) NACK for 0050.2 1) + tasks.run_certutil(master, ['-L', '-n', cls.adcert1, '-a', '>', + cls.adcert1_file], cls.reqdir) + tasks.run_certutil(master, ['-L', '-n', cls.adcert2, '-a', '>', + cls.adcert2_file], cls.reqdir) IMO thus should raise an error if failed, but previously you set raiseonerr=False (multiple times) 2) + cls.ad = cls.ad_domains[0].ads[0] + cls.ad_domain = cls.ad.domain.name + cls.aduser = "testuser@%s" % cls.ad_domain + cls.adcert1 = 'MyCert1' + cls.adcert2 = 'MyCert2' + cls.adcert1_file = cls.adcert1 + '.crt' + cls.adcert2_file = cls.adcert2 + '.crt' New definitions of variables/constants should be directly in class not in install method, adding new class variables in classmethod is the same evil as adding instance variables outside __init__ 3) I have question, why do you need AD for this test? AFAIK you can use ID overrides without AD Martin^3 From mbasti at redhat.com Tue Aug 30 12:09:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 30 Aug 2016 14:09:29 +0200 Subject: [Freeipa-devel] [PATCH] 0220 move /bin/ipa to freeipa-client In-Reply-To: References: <20160825092720.242twohhey7pf2vs@redhat.com> <25322a89-9557-7790-7f81-af1aedcc8807@redhat.com> <20160825110930.vimskikhtn2lwmmy@redhat.com> Message-ID: On 30.08.2016 09:27, Jan Cholasta wrote: > On 25.8.2016 13:09, Alexander Bokovoy wrote: >> On Thu, 25 Aug 2016, Jan Cholasta wrote: >>> Hi, >>> >>> On 25.8.2016 11:27, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> attached patch moves ipa CLI to freeipa-client and obsoletes >>>> freeipa-admintools >>> >>> The Obsoletes (both) should be on version < 4.4.1 rather than >>> %{version}, as per Fedora packaging guidelines [1]. >>> >>> Please move the Obsoletes and Provides on %{name}-admintools right >>> below Group (Obsoletes first) and put a newline between the >>> %{alt_name}-client and %{alt_name}-admintools blocks, for consistent >>> layout accross all subpackages in the spec file. >>> >>>> >>>> Solves https://fedorahosted.org/freeipa/ticket/5934 >>>> >>>> Here is how upgrade looks when running 'dnf': >>>> >>>> Upgrading: >>>> freeipa-client x86_64 >>>> 4.4.0.201608250913GIT9c20682-0.fc24 @commandline >>>> 146 k >>>> replacing freeipa-admintools.noarch >>>> 4.4.0.201608051228GIT590e30f-0.fc24 >>> >>> I'm going to test with yum as well, for RHEL and CentOS. >> Updated patch attached. > > Thanks, ACK. > > Pushed to master: b91ba39d627d36d1a62ebf97a987a2579404395e > I'm experiencing this: [root at vm-058-017 ~]# dnf reinstall /home/mbasti/freeipa-rpms/* -y Last metadata expiration check: 1:32:14 ago on Tue Aug 30 12:32:32 2016. Dependencies resolved. =================================================================================================================================================================================================================== Package Arch Version Repository Size =================================================================================================================================================================================================================== Reinstalling: freeipa-client x86_64 4.4.0-0.fc24 @commandline 146 k replacing freeipa-admintools.noarch 4.4.0-0.fc24 freeipa-client-common noarch 4.4.0-0.fc24 @commandline 28 k freeipa-common noarch 4.4.0-0.fc24 @commandline 386 k freeipa-debuginfo x86_64 4.4.0-0.fc24 @commandline 934 k freeipa-python-compat noarch 4.4.0-0.fc24 @commandline 22 k freeipa-server x86_64 4.4.0-0.fc24 @commandline 350 k freeipa-server-common noarch 4.4.0-0.fc24 @commandline 524 k freeipa-server-dns noarch 4.4.0-0.fc24 @commandline 26 k freeipa-server-trust-ad x86_64 4.4.0-0.fc24 @commandline 116 k python2-ipaclient noarch 4.4.0-0.fc24 @commandline 443 k python2-ipalib noarch 4.4.0-0.fc24 @commandline 560 k python2-ipaserver noarch 4.4.0-0.fc24 @commandline 1.2 M python2-ipatests noarch 4.4.0-0.fc24 @commandline 840 k python3-ipaclient noarch 4.4.0-0.fc24 @commandline 626 k python3-ipalib noarch 4.4.0-0.fc24 @commandline 568 k python3-ipatests noarch 4.4.0-0.fc24 @commandline 842 k Transaction Summary =================================================================================================================================================================================================================== Total size: 7.4 M Downloading Packages: Running transaction check Error: transaction check vs depsolve: ipa-admintools conflicts with freeipa-client-4.4.0-0.fc24.x86_64 freeipa-admintools < 4.4.1 is obsoleted by freeipa-client-4.4.0-0.fc24.x86_64 ipa-admintools conflicts with (installed) freeipa-admintools-4.4.0-0.fc24.noarch To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'. You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix the issue. From freeipa-github-notification at redhat.com Tue Aug 30 12:21:26 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Tue, 30 Aug 2016 14:21:26 +0200 Subject: [Freeipa-devel] [freeipa PR#38] Removed incorrect check for returncode (closed) In-Reply-To: References: Message-ID: ofayans's pull request #38: "Removed incorrect check for returncode" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/38 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/38/head:pr38 git checkout pr38 From jcholast at redhat.com Tue Aug 30 12:43:31 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 30 Aug 2016 14:43:31 +0200 Subject: [Freeipa-devel] [PATCH] 0220 move /bin/ipa to freeipa-client In-Reply-To: References: <20160825092720.242twohhey7pf2vs@redhat.com> <25322a89-9557-7790-7f81-af1aedcc8807@redhat.com> <20160825110930.vimskikhtn2lwmmy@redhat.com> Message-ID: <81f53d12-c736-ea5d-55d0-49d87a86bf1e@redhat.com> On 30.8.2016 14:09, Martin Basti wrote: > > > On 30.08.2016 09:27, Jan Cholasta wrote: >> On 25.8.2016 13:09, Alexander Bokovoy wrote: >>> On Thu, 25 Aug 2016, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 25.8.2016 11:27, Alexander Bokovoy wrote: >>>>> Hi, >>>>> >>>>> attached patch moves ipa CLI to freeipa-client and obsoletes >>>>> freeipa-admintools >>>> >>>> The Obsoletes (both) should be on version < 4.4.1 rather than >>>> %{version}, as per Fedora packaging guidelines [1]. >>>> >>>> Please move the Obsoletes and Provides on %{name}-admintools right >>>> below Group (Obsoletes first) and put a newline between the >>>> %{alt_name}-client and %{alt_name}-admintools blocks, for consistent >>>> layout accross all subpackages in the spec file. >>>> >>>>> >>>>> Solves https://fedorahosted.org/freeipa/ticket/5934 >>>>> >>>>> Here is how upgrade looks when running 'dnf': >>>>> >>>>> Upgrading: >>>>> freeipa-client x86_64 >>>>> 4.4.0.201608250913GIT9c20682-0.fc24 @commandline >>>>> 146 k >>>>> replacing freeipa-admintools.noarch >>>>> 4.4.0.201608051228GIT590e30f-0.fc24 >>>> >>>> I'm going to test with yum as well, for RHEL and CentOS. >>> Updated patch attached. >> >> Thanks, ACK. >> >> Pushed to master: b91ba39d627d36d1a62ebf97a987a2579404395e >> > I'm experiencing this: > > [root at vm-058-017 ~]# dnf reinstall /home/mbasti/freeipa-rpms/* -y > Last metadata expiration check: 1:32:14 ago on Tue Aug 30 12:32:32 2016. > Dependencies resolved. > =================================================================================================================================================================================================================== > > Package Arch Version Repository > Size > =================================================================================================================================================================================================================== > > Reinstalling: > freeipa-client x86_64 4.4.0-0.fc24 > @commandline 146 k > replacing freeipa-admintools.noarch 4.4.0-0.fc24 > freeipa-client-common noarch 4.4.0-0.fc24 > @commandline 28 k > freeipa-common noarch 4.4.0-0.fc24 > @commandline 386 k > freeipa-debuginfo x86_64 4.4.0-0.fc24 > @commandline 934 k > freeipa-python-compat noarch 4.4.0-0.fc24 > @commandline 22 k > freeipa-server x86_64 4.4.0-0.fc24 > @commandline 350 k > freeipa-server-common noarch 4.4.0-0.fc24 > @commandline 524 k > freeipa-server-dns noarch 4.4.0-0.fc24 > @commandline 26 k > freeipa-server-trust-ad x86_64 4.4.0-0.fc24 > @commandline 116 k > python2-ipaclient noarch 4.4.0-0.fc24 > @commandline 443 k > python2-ipalib noarch 4.4.0-0.fc24 > @commandline 560 k > python2-ipaserver noarch 4.4.0-0.fc24 > @commandline 1.2 M > python2-ipatests noarch 4.4.0-0.fc24 > @commandline 840 k > python3-ipaclient noarch 4.4.0-0.fc24 > @commandline 626 k > python3-ipalib noarch 4.4.0-0.fc24 > @commandline 568 k > python3-ipatests noarch 4.4.0-0.fc24 > @commandline 842 k > > Transaction Summary > =================================================================================================================================================================================================================== > > > Total size: 7.4 M > Downloading Packages: > Running transaction check > Error: transaction check vs depsolve: > ipa-admintools conflicts with freeipa-client-4.4.0-0.fc24.x86_64 > freeipa-admintools < 4.4.1 is obsoleted by > freeipa-client-4.4.0-0.fc24.x86_64 > ipa-admintools conflicts with (installed) > freeipa-admintools-4.4.0-0.fc24.noarch > To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'. > You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix > the issue. I think this will go away by itself once we release 4.4.1. -- Jan Cholasta From abokovoy at redhat.com Tue Aug 30 13:00:13 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 30 Aug 2016 16:00:13 +0300 Subject: [Freeipa-devel] Release 4.4.1 planning Message-ID: <20160830130013.yjixfqvfc6cx6m65@redhat.com> Hi, we have a plan to release FreeIPA 4.4.1 on Wednesday, Aug 31st. I started preparing a release page: http://www.freeipa.org/page/Releases/4.4.1 It has staggering 140+ closed tickets already. Please help me with filling in enhancements and bug fixes sections. -- / Alexander Bokovoy From simo at redhat.com Tue Aug 30 13:34:14 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 30 Aug 2016 09:34:14 -0400 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1a254cbc-120f-1645-6a4e-20ef5563719f@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1a254cbc-120f-1645-6a4e-20ef5563719f@redhat.com> Message-ID: <1472564054.5257.50.camel@redhat.com> On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote: > On 08/26/2016 05:37 PM, Simo Sorce wrote: > > On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: > >> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: > >>> On Fri, 26 Aug 2016, Simo Sorce wrote: > >>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: > >>>>>> I miss "why" part of "To be able to handle backward compatibility > >>>>> with > >>>>>> ease, a new object called ipaHBACRulev2 is introduced. " in the > >>>>> design > >>>>>> page. If the reason is the above - old client's should ignore time > >>>>> rules > >>>>>> then it has to be mentioned there. Otherwise I don't see a reason to > >>>>>> introduce a new object type instead of extending the current. > >>>>> How do you want to enforce HBAC rule that have set time from 10 to 14 > >>>>> everyday? With the same objectclass old clients will allow this HBAC > >>>>> for > >>>>> all day. Isn't this CVE? > >>>> This is a discussion worth having. > >>>> > >>>> In general it is a CVE only if an authorization mechanism fails to work > >>>> as advertised. > >>>> > >>>> If you make it clear that old clients *DO NOT* respect time rules then > >>>> there is no CVE material, it is working as "described". > >>>> > >>>> The admins already have a way to not set those rules for older clients > >>>> by simply grouping newer clients in a different host group and applying > >>>> time rules only there. > >>>> > >>>> So the question really is: should we allow admins to apply an HBAC Rule > >>>> potentially to older clients that do not understand it and will > >>>> therefore allow access at any time of the day, or should we prevent it ? > >>>> > >>>> This is a hard question to answer and can go both ways. > >>>> > >>>> A time rule may be something that admins want to enforce at all cost or > >>>> deny access. In this case a client that fails to handle it would be a > >>>> problem. > >>>> > >>>> But it may be something that is just used for defense in depth and not a > >>>> strictly hard requirement. In this case allowing older clients would > >>>> make it an easy transition as you just set up the rule and the client > >>>> will start enforcing the time when it is upgraded but work otherwise > >>>> with the same rules. > >>>> > >>>> I am a bit conflicted on trying to decide what scenario we should > >>>> target, but the second one appeals to me because host groups do already > >>>> give admins a good way to apply rules to a specific set of hosts and > >>>> exclude old clients w/o us making it a hard rule. > >>>> OTOH if an admin does not understand this difference, they may be > >>>> surprised to find out there are clients that do not honor it. > >>>> > >>>> Perhaps we could find a way to set a flag on the rule such that when set > >>>> (and only when set) older clients get excluded by way of changing the > >>>> objectlass or something else to similar effect. > >>>> > >>>> Open to discussion. > >>> At this point using new object class becomes an attractive approach. We > >>> don't have means to exclude HBAC rules other than applying them > >>> per-host/hostgroup. We also have no deny rules. > >>> > >>> I have another idea: what about enforcing time rules always to apply > >>> per-host or per-hostgroup by default? Add --force option to override the > >>> behavior but default to not allow --hostcat=all. This would raise > >>> awareness and make sure admins are actually applying these rules with > >>> intention. > >> This sounds like a good idea, but it is not a silver bullet I am afraid. > >> > >> Simo. > > I was thinking that for future proofing we could add a version field, > > then reasoned more and realized that changing the object class is > > basically the same thing. > > > > There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass. > > (I know 389ds allows us to do an LDAPv3 illegal operation and change it, > > but I do not like to depend on that behavoir). > > > > Now looking into this I had an idea to solve the problem of legacy > > clients without having to swap classes. > > We can redefine the accessRuleType attribute to be a "capability" type. > > > > Ie rules that have a timeAccess component will be of type > > "allow_with_time" instead of just "allow". > > Old clients are supposed to search with accessRuleType=allow (and I can > > see that SSSD does that), so an older client will fail to get those > > rules as they won't match. > > > > New clients instead can recognize both types. > > > > Also if we need a future extension we will simpy add a new access rule > > type and we can have the same effect. > > The nice thing is that accessRyleType is defined as multivalue (no > > SINGLE in schema) so we may actually create compatible rules if we want > > to. > > Ie we could set both "allow" and "allow_with_time" on an object for > > cases where the admin wants to enforce the time part only o newer client > > but otherwise apply the rule to any client. > > > > This should give us the best of all options at once. > > > > Thoughts ? > > > > Simo. > > > Sorry to join the discussion so late, I was away yesterday. > > I have to say I too like this idea much better than fiddling with the > objectClasses. Also, I believe that accessRuleType was originally > actually used to distinguish newer version of HBAC rules from the older > so we may just do this again and profit from its original purpose. To > top it off, this change should be really easy to implement to what I > currently have on SSSD side. > > I was just wondering - would you propose for every newly created rule to > have the new accessRuleType set to "allow_with_time" or should the type > change with addition of time rules to the HBAC rule as it does > currently? Also, should the user be able to modify the type so that a > rule with the new type is also visible for older clients (=> he could > add "allow" to type anytime)? Rules of type allow_with_time will not work on older clients, so we should probably default to just the old "allow" schema. I think in the first implementation the framework/cli/ui should not emphasize this attribute but simply replace allow -> allow_with_time if a time attribute is added. In future we may give control of it and allow even to set multiple values, after we discuss better if that should be done, and with ample warnings to admins. Also setting a time rule makes a rule incompatible with older clients so we should spell it clearly in the CLI/UI with a warning message that this rule will not apply at all to older clients. > Thanks for your ideas, I am very happy with what you suggested here :) Thank you. Simo. -- Simo Sorce * Red Hat, Inc * New York From freeipa-github-notification at redhat.com Tue Aug 30 14:43:58 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 16:43:58 +0200 Subject: [Freeipa-devel] [freeipa PR#38] Removed incorrect check for returncode (+rejected) In-Reply-To: References: Message-ID: ofayans's pull request #38: "Removed incorrect check for returncode" label *rejected* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/38 From freeipa-github-notification at redhat.com Tue Aug 30 14:44:20 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 30 Aug 2016 16:44:20 +0200 Subject: [Freeipa-devel] [freeipa PR#38] Removed incorrect check for returncode (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ IPA code should be fixed not tests """ See the full comment at https://github.com/freeipa/freeipa/pull/38#issuecomment-243463585 From mharmsen at redhat.com Wed Aug 31 00:29:01 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 30 Aug 2016 18:29:01 -0600 Subject: [Freeipa-devel] Karma Requests for pki-core-10.3.5-4 Message-ID: *The following updated candidate builds of pki-core 10.3.5 on Fedora 24, 25, and 26 (rawhide) consist of the following: * * *Fedora 24* o *pki-core-10.3.5-4.fc24 * * *Fedora 25* o *pki-core-10.3.5-4.fc25 * * *Fedora 26* o *pki-core-10.3.5-4.fc26 * *Additionally, the CentOS 7 COPR EPEL Builds of Dogtag 10.3.3 were also updated: * * *https://copr.fedorainfracloud.org/coprs/g/pki/10.3.3/repo/epel-7/group_pki-10.3.3-epel-7.repo * [group_pki-10.3.3] name=Copr repo for 10.3.3 owned by @pki baseurl=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.3/epel-7-$basearch/ skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.3/pubkey.gpg enabled=1 enabled_metadata=1 *These builds address the following PKI tickets: * * PKI TRAC Ticket #1578 - Authentication Instance Id PinDirEnrollment with authType value as SslclientAuth is not working * PKI TRAC Ticket #2414 - pki pkcs12-cert-del shows a successfully deleted message when a wrong nickname is provided * PKI TRAC Ticket #2423 - pki_ca_signing_token when not specified does not fallback to pki_token_name value * PKI TRAC Ticket #2436 - Dogtag 10.3.6: Miscellaneous Enhancements o added check for pki-server-nuxwdog parameter * PKI TRAC Ticket #2439 - Outdated deployment descriptors in upgraded server *Please provide Karma for the following builds: * * *Fedora 24* o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-36fa3fd8c3 pki-core-10.3.5-4.fc24 * * *Fedora 25* o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-abb1e5d2a6 pki-core-10.3.5-4.fc25 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Aug 31 10:08:33 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 31 Aug 2016 12:08:33 +0200 Subject: [Freeipa-devel] [PATCH] 0024 memory leak in ipapwd plugin In-Reply-To: <11333e12-f5f7-4f5c-df4f-960447ad5c0d@redhat.com> References: <57AACBB9.1050608@redhat.com> <20160810092441.wmgv6jtrrej7bbxi@redhat.com> <57AB55A3.6040305@redhat.com> <20160810171927.fzjktnorevhlv46e@redhat.com> <57AC8407.70806@redhat.com> <20160811143903.id66th5o63vhkpqi@redhat.com> <11333e12-f5f7-4f5c-df4f-960447ad5c0d@redhat.com> Message-ID: <2336e8ea-c938-b386-376a-cde83d815ed9@redhat.com> On 30.08.2016 13:27, Martin Basti wrote: > > > On 11.08.2016 16:39, Alexander Bokovoy wrote: >> On Thu, 11 Aug 2016, thierry bordaz wrote: >>>>> + /* rc should always be 0 (else slapi_sdn_new_dn_byref >>>>> should have sigsev) >>>>> + * but if we end in rc==LDAP_OPERATIONS_ERROR be sure to >>>>> stop here >>>>> + * because ret is not significant */ >>>> A short note here. You talk about slapi_sdn_new_dn_byref() but your >>>> patch replaces that with slapi_sdn_new_dn_byval(). Does the comment >>>> still apply? >>>> >>>>> + if (rc != 0) { >>>>> + LOG_OOM(); >>>>> + goto free_and_return; >>>>> + } >>>>> + >>>>> if (ret == 0) { >>>>> Slapi_Value *cpw[2] = { NULL, NULL }; >>>>> Slapi_Value *pw; >>>>> -- >>>>> 2.7.4 >>>>> >>>> >>>> >>> Good catch Alexander. Yes the comment contained a wrong cut/paste >> ACK. >> >> > Is there a ticket for this? > Pushed to master: b942b00ac7bca7e2864c7dc513d25983556916ff From freeipa-github-notification at redhat.com Wed Aug 31 10:36:11 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Wed, 31 Aug 2016 12:36:11 +0200 Subject: [Freeipa-devel] [freeipa PR#34] dns: prompt for missing record parts in CLI (synchronize) In-Reply-To: References: Message-ID: jcholast's pull request #34: " dns: prompt for missing record parts in CLI" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/34 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/34/head:pr34 git checkout pr34 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-34.patch Type: text/x-diff Size: 5011 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Aug 31 10:37:09 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Wed, 31 Aug 2016 12:37:09 +0200 Subject: [Freeipa-devel] [freeipa PR#34] dns: prompt for missing record parts in CLI (comment) In-Reply-To: References: Message-ID: jcholast commented on a pull request """ I have decided to instead copy & paste the code, as it exists solely for the purpose of supporting old servers, so it should not get any additional improvements in the future. """ See the full comment at https://github.com/freeipa/freeipa/pull/34#issuecomment-243725653 From slaznick at redhat.com Wed Aug 31 10:42:22 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Wed, 31 Aug 2016 12:42:22 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: <1472564054.5257.50.camel@redhat.com> References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1a254cbc-120f-1645-6a4e-20ef5563719f@redhat.com> <1472564054.5257.50.camel@redhat.com> Message-ID: On 08/30/2016 03:34 PM, Simo Sorce wrote: > On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote: >> On 08/26/2016 05:37 PM, Simo Sorce wrote: >>> On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: >>>> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: >>>>> On Fri, 26 Aug 2016, Simo Sorce wrote: >>>>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: >>>>>>>> I miss "why" part of "To be able to handle backward compatibility >>>>>>> with >>>>>>>> ease, a new object called ipaHBACRulev2 is introduced. " in the >>>>>>> design >>>>>>>> page. If the reason is the above - old client's should ignore time >>>>>>> rules >>>>>>>> then it has to be mentioned there. Otherwise I don't see a reason to >>>>>>>> introduce a new object type instead of extending the current. >>>>>>> How do you want to enforce HBAC rule that have set time from 10 to 14 >>>>>>> everyday? With the same objectclass old clients will allow this HBAC >>>>>>> for >>>>>>> all day. Isn't this CVE? >>>>>> This is a discussion worth having. >>>>>> >>>>>> In general it is a CVE only if an authorization mechanism fails to work >>>>>> as advertised. >>>>>> >>>>>> If you make it clear that old clients *DO NOT* respect time rules then >>>>>> there is no CVE material, it is working as "described". >>>>>> >>>>>> The admins already have a way to not set those rules for older clients >>>>>> by simply grouping newer clients in a different host group and applying >>>>>> time rules only there. >>>>>> >>>>>> So the question really is: should we allow admins to apply an HBAC Rule >>>>>> potentially to older clients that do not understand it and will >>>>>> therefore allow access at any time of the day, or should we prevent it ? >>>>>> >>>>>> This is a hard question to answer and can go both ways. >>>>>> >>>>>> A time rule may be something that admins want to enforce at all cost or >>>>>> deny access. In this case a client that fails to handle it would be a >>>>>> problem. >>>>>> >>>>>> But it may be something that is just used for defense in depth and not a >>>>>> strictly hard requirement. In this case allowing older clients would >>>>>> make it an easy transition as you just set up the rule and the client >>>>>> will start enforcing the time when it is upgraded but work otherwise >>>>>> with the same rules. >>>>>> >>>>>> I am a bit conflicted on trying to decide what scenario we should >>>>>> target, but the second one appeals to me because host groups do already >>>>>> give admins a good way to apply rules to a specific set of hosts and >>>>>> exclude old clients w/o us making it a hard rule. >>>>>> OTOH if an admin does not understand this difference, they may be >>>>>> surprised to find out there are clients that do not honor it. >>>>>> >>>>>> Perhaps we could find a way to set a flag on the rule such that when set >>>>>> (and only when set) older clients get excluded by way of changing the >>>>>> objectlass or something else to similar effect. >>>>>> >>>>>> Open to discussion. >>>>> At this point using new object class becomes an attractive approach. We >>>>> don't have means to exclude HBAC rules other than applying them >>>>> per-host/hostgroup. We also have no deny rules. >>>>> >>>>> I have another idea: what about enforcing time rules always to apply >>>>> per-host or per-hostgroup by default? Add --force option to override the >>>>> behavior but default to not allow --hostcat=all. This would raise >>>>> awareness and make sure admins are actually applying these rules with >>>>> intention. >>>> This sounds like a good idea, but it is not a silver bullet I am afraid. >>>> >>>> Simo. >>> I was thinking that for future proofing we could add a version field, >>> then reasoned more and realized that changing the object class is >>> basically the same thing. >>> >>> There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass. >>> (I know 389ds allows us to do an LDAPv3 illegal operation and change it, >>> but I do not like to depend on that behavoir). >>> >>> Now looking into this I had an idea to solve the problem of legacy >>> clients without having to swap classes. >>> We can redefine the accessRuleType attribute to be a "capability" type. >>> >>> Ie rules that have a timeAccess component will be of type >>> "allow_with_time" instead of just "allow". >>> Old clients are supposed to search with accessRuleType=allow (and I can >>> see that SSSD does that), so an older client will fail to get those >>> rules as they won't match. >>> >>> New clients instead can recognize both types. >>> >>> Also if we need a future extension we will simpy add a new access rule >>> type and we can have the same effect. >>> The nice thing is that accessRyleType is defined as multivalue (no >>> SINGLE in schema) so we may actually create compatible rules if we want >>> to. >>> Ie we could set both "allow" and "allow_with_time" on an object for >>> cases where the admin wants to enforce the time part only o newer client >>> but otherwise apply the rule to any client. >>> >>> This should give us the best of all options at once. >>> >>> Thoughts ? >>> >>> Simo. >>> >> Sorry to join the discussion so late, I was away yesterday. >> >> I have to say I too like this idea much better than fiddling with the >> objectClasses. Also, I believe that accessRuleType was originally >> actually used to distinguish newer version of HBAC rules from the older >> so we may just do this again and profit from its original purpose. To >> top it off, this change should be really easy to implement to what I >> currently have on SSSD side. >> >> I was just wondering - would you propose for every newly created rule to >> have the new accessRuleType set to "allow_with_time" or should the type >> change with addition of time rules to the HBAC rule as it does >> currently? Also, should the user be able to modify the type so that a >> rule with the new type is also visible for older clients (=> he could >> add "allow" to type anytime)? > Rules of type allow_with_time will not work on older clients, so we > should probably default to just the old "allow" schema. > > I think in the first implementation the framework/cli/ui should not > emphasize this attribute but simply replace allow -> allow_with_time if > a time attribute is added. > > In future we may give control of it and allow even to set multiple > values, after we discuss better if that should be done, and with ample > warnings to admins. > > Also setting a time rule makes a rule incompatible with older clients so > we should spell it clearly in the CLI/UI with a warning message that > this rule will not apply at all to older clients. > >> Thanks for your ideas, I am very happy with what you suggested here :) > Thank you. > > Simo. > So - can we all agree on a solution? I took an extra half an hour and created the accessRuleType solution on top of what I currently have, see patches attached to get the picture what the change would mean for what I currently have in https://github.com/stlaz/freeipa/tree/timerules_2 and https://github.com/stlaz/sssd/tree/freeipa-trac-547_2. Note that the sssd patch is really just to get a picture, it currently causes sssd_be to core dump, not sure why and don't want to waste time debugging it right now. I myself would in the end rather go for objectClasses implementation as new rules are not shown to old clients which seems correct as there's no confusion for admins who might scratch their heads at old clients with no idea why their HBAC rules don't apply otherwise. -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd.patch Type: text/x-patch Size: 4653 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa.patch Type: text/x-patch Size: 15174 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Aug 31 10:51:14 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Wed, 31 Aug 2016 12:51:14 +0200 Subject: [Freeipa-devel] [freeipa PR#34] dns: prompt for missing record parts in CLI (synchronize) In-Reply-To: References: Message-ID: jcholast's pull request #34: " dns: prompt for missing record parts in CLI" was synchronize See the full pull-request at https://github.com/freeipa/freeipa/pull/34 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/34/head:pr34 git checkout pr34 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-34.patch Type: text/x-diff Size: 5044 bytes Desc: not available URL: From pspacek at redhat.com Wed Aug 31 10:57:31 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 31 Aug 2016 12:57:31 +0200 Subject: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies In-Reply-To: References: <5f64db5a-8903-48a5-7d5e-ff6251667738@redhat.com> <7f48c6dd-d5b0-2587-dbe9-914fa470916d@redhat.com> <20160826102021.h64hfjrvky4bitrw@redhat.com> <188ea28b-ddff-2d8b-c515-c5bdbda8f56d@redhat.com> <1472222393.20746.86.camel@redhat.com> <20160826150943.5zmmub2ntc4vqqij@redhat.com> <1472225168.20746.95.camel@redhat.com> <1472225854.20746.104.camel@redhat.com> <1a254cbc-120f-1645-6a4e-20ef5563719f@redhat.com> <1472564054.5257.50.camel@redhat.com> Message-ID: <5b5e276d-8d3d-53cb-a4a4-fa285f0662d9@redhat.com> On 31.8.2016 12:42, Standa Laznicka wrote: > On 08/30/2016 03:34 PM, Simo Sorce wrote: >> On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote: >>> On 08/26/2016 05:37 PM, Simo Sorce wrote: >>>> On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: >>>>> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: >>>>>> On Fri, 26 Aug 2016, Simo Sorce wrote: >>>>>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: >>>>>>>>> I miss "why" part of "To be able to handle backward compatibility >>>>>>>> with >>>>>>>>> ease, a new object called ipaHBACRulev2 is introduced. " in the >>>>>>>> design >>>>>>>>> page. If the reason is the above - old client's should ignore time >>>>>>>> rules >>>>>>>>> then it has to be mentioned there. Otherwise I don't see a reason to >>>>>>>>> introduce a new object type instead of extending the current. >>>>>>>> How do you want to enforce HBAC rule that have set time from 10 to 14 >>>>>>>> everyday? With the same objectclass old clients will allow this HBAC >>>>>>>> for >>>>>>>> all day. Isn't this CVE? >>>>>>> This is a discussion worth having. >>>>>>> >>>>>>> In general it is a CVE only if an authorization mechanism fails to work >>>>>>> as advertised. >>>>>>> >>>>>>> If you make it clear that old clients *DO NOT* respect time rules then >>>>>>> there is no CVE material, it is working as "described". >>>>>>> >>>>>>> The admins already have a way to not set those rules for older clients >>>>>>> by simply grouping newer clients in a different host group and applying >>>>>>> time rules only there. >>>>>>> >>>>>>> So the question really is: should we allow admins to apply an HBAC Rule >>>>>>> potentially to older clients that do not understand it and will >>>>>>> therefore allow access at any time of the day, or should we prevent it ? >>>>>>> >>>>>>> This is a hard question to answer and can go both ways. >>>>>>> >>>>>>> A time rule may be something that admins want to enforce at all cost or >>>>>>> deny access. In this case a client that fails to handle it would be a >>>>>>> problem. >>>>>>> >>>>>>> But it may be something that is just used for defense in depth and not a >>>>>>> strictly hard requirement. In this case allowing older clients would >>>>>>> make it an easy transition as you just set up the rule and the client >>>>>>> will start enforcing the time when it is upgraded but work otherwise >>>>>>> with the same rules. >>>>>>> >>>>>>> I am a bit conflicted on trying to decide what scenario we should >>>>>>> target, but the second one appeals to me because host groups do already >>>>>>> give admins a good way to apply rules to a specific set of hosts and >>>>>>> exclude old clients w/o us making it a hard rule. >>>>>>> OTOH if an admin does not understand this difference, they may be >>>>>>> surprised to find out there are clients that do not honor it. >>>>>>> >>>>>>> Perhaps we could find a way to set a flag on the rule such that when set >>>>>>> (and only when set) older clients get excluded by way of changing the >>>>>>> objectlass or something else to similar effect. >>>>>>> >>>>>>> Open to discussion. >>>>>> At this point using new object class becomes an attractive approach. We >>>>>> don't have means to exclude HBAC rules other than applying them >>>>>> per-host/hostgroup. We also have no deny rules. >>>>>> >>>>>> I have another idea: what about enforcing time rules always to apply >>>>>> per-host or per-hostgroup by default? Add --force option to override the >>>>>> behavior but default to not allow --hostcat=all. This would raise >>>>>> awareness and make sure admins are actually applying these rules with >>>>>> intention. >>>>> This sounds like a good idea, but it is not a silver bullet I am afraid. >>>>> >>>>> Simo. >>>> I was thinking that for future proofing we could add a version field, >>>> then reasoned more and realized that changing the object class is >>>> basically the same thing. >>>> >>>> There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass. >>>> (I know 389ds allows us to do an LDAPv3 illegal operation and change it, >>>> but I do not like to depend on that behavoir). >>>> >>>> Now looking into this I had an idea to solve the problem of legacy >>>> clients without having to swap classes. >>>> We can redefine the accessRuleType attribute to be a "capability" type. >>>> >>>> Ie rules that have a timeAccess component will be of type >>>> "allow_with_time" instead of just "allow". >>>> Old clients are supposed to search with accessRuleType=allow (and I can >>>> see that SSSD does that), so an older client will fail to get those >>>> rules as they won't match. >>>> >>>> New clients instead can recognize both types. >>>> >>>> Also if we need a future extension we will simpy add a new access rule >>>> type and we can have the same effect. >>>> The nice thing is that accessRyleType is defined as multivalue (no >>>> SINGLE in schema) so we may actually create compatible rules if we want >>>> to. >>>> Ie we could set both "allow" and "allow_with_time" on an object for >>>> cases where the admin wants to enforce the time part only o newer client >>>> but otherwise apply the rule to any client. >>>> >>>> This should give us the best of all options at once. >>>> >>>> Thoughts ? >>>> >>>> Simo. >>>> >>> Sorry to join the discussion so late, I was away yesterday. >>> >>> I have to say I too like this idea much better than fiddling with the >>> objectClasses. Also, I believe that accessRuleType was originally >>> actually used to distinguish newer version of HBAC rules from the older >>> so we may just do this again and profit from its original purpose. To >>> top it off, this change should be really easy to implement to what I >>> currently have on SSSD side. >>> >>> I was just wondering - would you propose for every newly created rule to >>> have the new accessRuleType set to "allow_with_time" or should the type >>> change with addition of time rules to the HBAC rule as it does >>> currently? Also, should the user be able to modify the type so that a >>> rule with the new type is also visible for older clients (=> he could >>> add "allow" to type anytime)? >> Rules of type allow_with_time will not work on older clients, so we >> should probably default to just the old "allow" schema. >> >> I think in the first implementation the framework/cli/ui should not >> emphasize this attribute but simply replace allow -> allow_with_time if >> a time attribute is added. >> >> In future we may give control of it and allow even to set multiple >> values, after we discuss better if that should be done, and with ample >> warnings to admins. >> >> Also setting a time rule makes a rule incompatible with older clients so >> we should spell it clearly in the CLI/UI with a warning message that >> this rule will not apply at all to older clients. >> >>> Thanks for your ideas, I am very happy with what you suggested here :) >> Thank you. >> >> Simo. >> > So - can we all agree on a solution? > > I took an extra half an hour and created the accessRuleType solution on top of > what I currently have, see patches attached to get the picture what the change > would mean for what I currently have in > https://github.com/stlaz/freeipa/tree/timerules_2 and > https://github.com/stlaz/sssd/tree/freeipa-trac-547_2. Note that the sssd > patch is really just to get a picture, it currently causes sssd_be to core > dump, not sure why and don't want to waste time debugging it right now. > > I myself would in the end rather go for objectClasses implementation as new > rules are not shown to old clients which seems correct as there's no confusion > for admins who might scratch their heads at old clients with no idea why their > HBAC rules don't apply otherwise. +1, I agree with Standa and Martin Basti. Let me repeat myself: I like the idea of "capabilities" in general but it needs proper design and detailed specification first. Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object class with clear definition of "capabilities" (without any obsolete cruft). That should be future proof and without any negative/unforeseen impact to existing clients + it matches what Jan Pazdziora plans to do for HBAC+URI. -- Petr^2 Spacek From mbasti at redhat.com Wed Aug 31 11:55:09 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 31 Aug 2016 13:55:09 +0200 Subject: [Freeipa-devel] Release 4.4.1 planning In-Reply-To: <20160830130013.yjixfqvfc6cx6m65@redhat.com> References: <20160830130013.yjixfqvfc6cx6m65@redhat.com> Message-ID: <21e693a1-cd5e-b5fe-c009-90ee058a9dc8@redhat.com> On 30.08.2016 15:00, Alexander Bokovoy wrote: > Hi, > > we have a plan to release FreeIPA 4.4.1 on Wednesday, Aug 31st. > > I started preparing a release page: > http://www.freeipa.org/page/Releases/4.4.1 > > It has staggering 140+ closed tickets already. > > Please help me with filling in enhancements and bug fixes sections. > We must postpone release today, fix for https://fedorahosted.org/freeipa/ticket/6226 pushed yesterday causes replica installation issues Sorry :-( From freeipa-github-notification at redhat.com Wed Aug 31 12:18:10 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 31 Aug 2016 14:18:10 +0200 Subject: [Freeipa-devel] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (opened) Message-ID: martbab's pull request #40: "do not use trusted forest name to construct domain admin principal" was opened PR body: """ When `trust-add` is supplied AD domain admin name without realm component, the code appends the uppercased AD forest root domain name to construct the full principal. This can cause authentication error, however, when external trust with non-root domain is requested. We should instead use the supplied DNS domain name (if valid) as a realm component. https://fedorahosted.org/freeipa/ticket/6277 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/40 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/40/head:pr40 git checkout pr40 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-40.patch Type: text/x-diff Size: 1367 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Aug 31 12:21:56 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Wed, 31 Aug 2016 14:21:56 +0200 Subject: [Freeipa-devel] [freeipa PR#17] Tests: Random issuer certificate can be added to a service (+ack) In-Reply-To: References: Message-ID: mirielka's pull request #17: "Tests: Random issuer certificate can be added to a service" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/17 From freeipa-github-notification at redhat.com Wed Aug 31 12:29:44 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 14:29:44 +0200 Subject: [Freeipa-devel] [freeipa PR#17] Tests: Random issuer certificate can be added to a service (+pushed) In-Reply-To: References: Message-ID: mirielka's pull request #17: "Tests: Random issuer certificate can be added to a service" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/17 From freeipa-github-notification at redhat.com Wed Aug 31 12:29:46 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 14:29:46 +0200 Subject: [Freeipa-devel] [freeipa PR#17] Tests: Random issuer certificate can be added to a service (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/36979ad0b6c021e6f8ec83606e9c9adcd6bb8053 """ See the full comment at https://github.com/freeipa/freeipa/pull/17#issuecomment-243748766 From freeipa-github-notification at redhat.com Wed Aug 31 12:29:47 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 14:29:47 +0200 Subject: [Freeipa-devel] [freeipa PR#17] Tests: Random issuer certificate can be added to a service (closed) In-Reply-To: References: Message-ID: mirielka's pull request #17: "Tests: Random issuer certificate can be added to a service" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/17 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/17/head:pr17 git checkout pr17 From freeipa-github-notification at redhat.com Wed Aug 31 12:36:23 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 31 Aug 2016 14:36:23 +0200 Subject: [Freeipa-devel] [freeipa PR#35] rpcserver: assume version 1 for unversioned command calls (comment) In-Reply-To: References: Message-ID: dkupka commented on a pull request """ Works for me """ See the full comment at https://github.com/freeipa/freeipa/pull/35#issuecomment-243750243 From freeipa-github-notification at redhat.com Wed Aug 31 12:36:25 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 31 Aug 2016 14:36:25 +0200 Subject: [Freeipa-devel] [freeipa PR#35] rpcserver: assume version 1 for unversioned command calls (+ack) In-Reply-To: References: Message-ID: jcholast's pull request #35: "rpcserver: assume version 1 for unversioned command calls" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/35 From mbasti at redhat.com Wed Aug 31 12:36:33 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 31 Aug 2016 14:36:33 +0200 Subject: [Freeipa-devel] [PATCH] restrict setkeytab operation In-Reply-To: <1469533105.18067.89.camel@redhat.com> References: <1469450405.18067.69.camel@redhat.com> <57962868.8090904@redhat.com> <1469458890.18067.72.camel@redhat.com> <57962BE5.60404@redhat.com> <1469460374.18067.79.camel@redhat.com> <1469533105.18067.89.camel@redhat.com> Message-ID: <801215e7-666d-4b1f-bbed-031d0b0b6c42@redhat.com> On 26.07.2016 13:38, Simo Sorce wrote: > On Mon, 2016-07-25 at 11:26 -0400, Simo Sorce wrote: >> On Mon, 2016-07-25 at 11:10 -0400, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote: >>>>> Simo Sorce wrote: >>>>>> As described in #232 start restricting the use of the setkeytab >>>>>> operation to just the computers objects. >>>>>> >>>>>> I haven't tested this with older RHEL/CentOS machines that actully use >>>>>> the setkeytab operation as I do not have such an old VM handy right now. >>>>>> >>>>>> Meanwhile I'd like to know if ppl agree with this approach. >>>>> What about services? >>>> Do we automatically acquire keytab for services in the old clients ? >>>> >>>> Are you thinking about scripted ipa-getkytab callouts ? >>> You are limiting access to host keytabs, what about service keytabs? >>> Should they be or are they now similarly restricted? >>> >>> Installers for something like Foreman may try to generate a service >>> keytab in its installer, probably using admin credentials. I am planning >>> to do the same in Openstack. >> Ok I'll amend the patch to allow service keytabs to still use the >> setkeytab control still, and restrict only users. >> However note that the idea of using this method is that admin can change >> this default on their own, so they can restrict more or less if they >> want, to that end I need to remember how to set a default that we do not >> override in the update file. >> >> Simo. >> > Amended patch to allow services too. > Only users are excluded. > > Simo. > > > bump for review -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Wed Aug 31 12:37:10 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 31 Aug 2016 14:37:10 +0200 Subject: [Freeipa-devel] [freeipa PR#35] rpcserver: assume version 1 for unversioned command calls (comment) In-Reply-To: References: Message-ID: dkupka commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/8891465247a0bab5d07f560f2c963f3ee56905f0 """ See the full comment at https://github.com/freeipa/freeipa/pull/35#issuecomment-243750424 From freeipa-github-notification at redhat.com Wed Aug 31 12:37:11 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 31 Aug 2016 14:37:11 +0200 Subject: [Freeipa-devel] [freeipa PR#35] rpcserver: assume version 1 for unversioned command calls (+pushed) In-Reply-To: References: Message-ID: jcholast's pull request #35: "rpcserver: assume version 1 for unversioned command calls" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/35 From freeipa-github-notification at redhat.com Wed Aug 31 12:37:12 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 31 Aug 2016 14:37:12 +0200 Subject: [Freeipa-devel] [freeipa PR#35] rpcserver: assume version 1 for unversioned command calls (closed) In-Reply-To: References: Message-ID: jcholast's pull request #35: "rpcserver: assume version 1 for unversioned command calls" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/35 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/35/head:pr35 git checkout pr35 From freeipa-github-notification at redhat.com Wed Aug 31 12:43:10 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 31 Aug 2016 14:43:10 +0200 Subject: [Freeipa-devel] [freeipa PR#41] Postpone enabling LDAPS in replica promotion (opened) Message-ID: tomaskrizek's pull request #41: "Postpone enabling LDAPS in replica promotion" was opened PR body: """ Fixes a bug that prevented ipa-replica-install with CA, because LDAPS was configured before the SSL cerificate was assigned. https://fedorahosted.org/freeipa/ticket/6226 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/41 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/41/head:pr41 git checkout pr41 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-41.patch Type: text/x-diff Size: 1755 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Aug 31 12:45:58 2016 From: freeipa-github-notification at redhat.com (abbra) Date: Wed, 31 Aug 2016 14:45:58 +0200 Subject: [Freeipa-devel] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (comment) In-Reply-To: References: Message-ID: abbra commented on a pull request """ NACK. This is wrong. In the case of external trust to a child domain we cannot run netr_DsRGetForestTrustInformation() against the child domain, regardless what credentials we have. Instead, we should run this request against the forest root domain using the credentials specified by the user. """ See the full comment at https://github.com/freeipa/freeipa/pull/40#issuecomment-243752391 From freeipa-github-notification at redhat.com Wed Aug 31 13:01:09 2016 From: freeipa-github-notification at redhat.com (abbra) Date: Wed, 31 Aug 2016 15:01:09 +0200 Subject: [Freeipa-devel] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (comment) In-Reply-To: References: Message-ID: abbra commented on a pull request """ Apologies. This is indeed a minor issue which is correctly fixed, so ACK for this one. Note, though, this will not help with the actual query because regardless of what credentials were used, AD DC of a child domain behaves wrongly in Windows Server 2012R2 by not following MS-NRPC 3.5.4.7.5. """ See the full comment at https://github.com/freeipa/freeipa/pull/40#issuecomment-243756126 From freeipa-github-notification at redhat.com Wed Aug 31 13:01:26 2016 From: freeipa-github-notification at redhat.com (abbra) Date: Wed, 31 Aug 2016 15:01:26 +0200 Subject: [Freeipa-devel] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (+ack) In-Reply-To: References: Message-ID: martbab's pull request #40: "do not use trusted forest name to construct domain admin principal" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/40 From freeipa-github-notification at redhat.com Wed Aug 31 13:03:48 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Wed, 31 Aug 2016 15:03:48 +0200 Subject: [Freeipa-devel] [freeipa PR#39] Tests: Add missing attributes to test_xmlrpc/test_trust tests (+ack) In-Reply-To: References: Message-ID: mirielka's pull request #39: "Tests: Add missing attributes to test_xmlrpc/test_trust tests" label *ack* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/39 From freeipa-github-notification at redhat.com Wed Aug 31 13:06:14 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 15:06:14 +0200 Subject: [Freeipa-devel] [freeipa PR#39] Tests: Add missing attributes to test_xmlrpc/test_trust tests (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/60e88038c43c2ea2afc7e48f3e8dbd9bcfe955e8 """ See the full comment at https://github.com/freeipa/freeipa/pull/39#issuecomment-243757482 From freeipa-github-notification at redhat.com Wed Aug 31 13:06:17 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 15:06:17 +0200 Subject: [Freeipa-devel] [freeipa PR#39] Tests: Add missing attributes to test_xmlrpc/test_trust tests (+pushed) In-Reply-To: References: Message-ID: mirielka's pull request #39: "Tests: Add missing attributes to test_xmlrpc/test_trust tests" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/39 From freeipa-github-notification at redhat.com Wed Aug 31 13:06:18 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 15:06:18 +0200 Subject: [Freeipa-devel] [freeipa PR#39] Tests: Add missing attributes to test_xmlrpc/test_trust tests (closed) In-Reply-To: References: Message-ID: mirielka's pull request #39: "Tests: Add missing attributes to test_xmlrpc/test_trust tests" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/39 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/39/head:pr39 git checkout pr39 From freeipa-github-notification at redhat.com Wed Aug 31 13:08:33 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 15:08:33 +0200 Subject: [Freeipa-devel] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (+pushed) In-Reply-To: References: Message-ID: martbab's pull request #40: "do not use trusted forest name to construct domain admin principal" label *pushed* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/40 From freeipa-github-notification at redhat.com Wed Aug 31 13:08:34 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 15:08:34 +0200 Subject: [Freeipa-devel] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/f32e0e4e522e09390f4295dd79f52d7a48877d3a """ See the full comment at https://github.com/freeipa/freeipa/pull/40#issuecomment-243758104 From freeipa-github-notification at redhat.com Wed Aug 31 13:08:35 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 15:08:35 +0200 Subject: [Freeipa-devel] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (closed) In-Reply-To: References: Message-ID: martbab's pull request #40: "do not use trusted forest name to construct domain admin principal" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/40 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/40/head:pr40 git checkout pr40 From freeipa-github-notification at redhat.com Wed Aug 31 13:52:09 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Wed, 31 Aug 2016 15:52:09 +0200 Subject: [Freeipa-devel] [freeipa PR#41] Postpone enabling LDAPS in replica promotion (comment) In-Reply-To: References: Message-ID: jcholast commented on a pull request """ `ipa-replica-install` fails with: ``` Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 448, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 438, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 786, in __enable_ssl self.nickname, self.fqdn, cadb) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 336, in create_server_cert cdb.issue_server_cert(self.certreq_fname, self.certder_fname) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 405, in issue_server_cert self.secdir, password, "ipaCert", **params) File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 156, in https_request method=method, headers=headers) File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 207, in _httplib_request raise NetworkError(uri=uri, error=str(e)) NetworkError: cannot connect to 'https://vm-058-011.abc.idm.lab.eng.brq.redhat.com:8443/ca/ee/ca/profileSubmitSSLClient': (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/41#issuecomment-243770659 From freeipa-github-notification at redhat.com Wed Aug 31 13:55:20 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Wed, 31 Aug 2016 15:55:20 +0200 Subject: [Freeipa-devel] [freeipa PR#41] Postpone enabling LDAPS in replica promotion (comment) In-Reply-To: References: Message-ID: jcholast commented on a pull request """ However, I don't think this should block the release of 4.4.1, so I would just revert 89de60c5d8ba64d619101a7498b8c4469b6e50ae and keep the ticket open. """ See the full comment at https://github.com/freeipa/freeipa/pull/41#issuecomment-243771692 From freeipa-github-notification at redhat.com Wed Aug 31 14:07:21 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 16:07:21 +0200 Subject: [Freeipa-devel] [freeipa PR#41] Postpone enabling LDAPS in replica promotion (closed) In-Reply-To: References: Message-ID: tomaskrizek's pull request #41: "Postpone enabling LDAPS in replica promotion" was closed See the full pull-request at https://github.com/freeipa/freeipa/pull/41 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/41/head:pr41 git checkout pr41 From freeipa-github-notification at redhat.com Wed Aug 31 14:07:23 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 16:07:23 +0200 Subject: [Freeipa-devel] [freeipa PR#41] Postpone enabling LDAPS in replica promotion (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Reverted. master: https://fedorahosted.org/freeipa/changeset/dd02741896844a6e14d60f267d9b1cb27b039241 """ See the full comment at https://github.com/freeipa/freeipa/pull/41#issuecomment-243775352 From freeipa-github-notification at redhat.com Wed Aug 31 14:07:28 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 16:07:28 +0200 Subject: [Freeipa-devel] [freeipa PR#41] Postpone enabling LDAPS in replica promotion (+rejected) In-Reply-To: References: Message-ID: tomaskrizek's pull request #41: "Postpone enabling LDAPS in replica promotion" label *rejected* has been added See the full pull-request at https://github.com/freeipa/freeipa/pull/41 From freeipa-github-notification at redhat.com Wed Aug 31 14:32:52 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Wed, 31 Aug 2016 16:32:52 +0200 Subject: [Freeipa-devel] [freeipa PR#42] Tests: Avoid skipping tests due to missing files (opened) Message-ID: mirielka's pull request #42: "Tests: Avoid skipping tests due to missing files" was opened PR body: """ When running test_install/test_updates and test_pkcs10/test_pkcs10 as outoftree, these are skipped with reason 'Unable to find test update files'. For outoftree tests wrong paths are checked for these files. Adding proper paths to test setup. https://fedorahosted.org/freeipa/ticket/6284 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/42 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/42/head:pr42 git checkout pr42 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-42.patch Type: text/x-diff Size: 1818 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Aug 31 14:58:59 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Wed, 31 Aug 2016 16:58:59 +0200 Subject: [Freeipa-devel] [freeipa PR#43] Tests: Fix regex errors in integration trust tests (opened) Message-ID: mirielka's pull request #43: "Tests: Fix regex errors in integration trust tests" was opened PR body: """ In integration trust tests some values are checked using regular expressions. Some of these expressions from recently added coverage have minor mistakes which causes the comparisons to fail. Providing fix for these regular expressions. https://fedorahosted.org/freeipa/ticket/6285 """ See the full pull-request at https://github.com/freeipa/freeipa/pull/43 ... or pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/43/head:pr43 git checkout pr43 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-43.patch Type: text/x-diff Size: 1986 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Aug 31 15:36:59 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 17:36:59 +0200 Subject: [Freeipa-devel] [freeipa PR#42] Tests: Avoid skipping tests due to missing files (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ I don't like this. Will we have if/elif for each possible location of where tests are executed. What changed? I'm sure those tests work in past. Why dir where test is executed was changed? """ See the full comment at https://github.com/freeipa/freeipa/pull/42#issuecomment-243804469 From freeipa-github-notification at redhat.com Wed Aug 31 15:43:16 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Wed, 31 Aug 2016 17:43:16 +0200 Subject: [Freeipa-devel] [freeipa PR#42] Tests: Avoid skipping tests due to missing files (comment) In-Reply-To: References: Message-ID: mirielka commented on a pull request """ So far these tests were skipped in outoftree jobs because they could not find the requested files. The reason is that intree the tests are run from parent directory of ipatests directory, whereas outoftree tests run from ipatests directory itself. Unless the path is added to tests or outoftree tests start running from parent directory, these tests will fail. """ See the full comment at https://github.com/freeipa/freeipa/pull/42#issuecomment-243806573 From freeipa-github-notification at redhat.com Wed Aug 31 15:43:29 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 31 Aug 2016 17:43:29 +0200 Subject: [Freeipa-devel] [freeipa PR#42] Tests: Avoid skipping tests due to missing files (comment) In-Reply-To: References: Message-ID: mbasti-rh commented on a pull request """ Probably instead of that magic, there could be: ``` self.testdir = os.path.abspath(os.path.dirname(__file__)) ``` It should always find the proper local directory And please in read_file, instead of plus sign, use os.path.join(self.testdir, filename) """ See the full comment at https://github.com/freeipa/freeipa/pull/42#issuecomment-243806638 From freeipa-github-notification at redhat.com Wed Aug 31 15:58:30 2016 From: freeipa-github-notification at redhat.com (LiptonB) Date: Wed, 31 Aug 2016 17:58:30 +0200 Subject: [Freeipa-devel] [freeipa PR#10] Client-side CSR autogeneration (comment) In-Reply-To: References: Message-ID: LiptonB commented on a pull request """ As discussed elsewhere, this script generation is a fairly low-level operation; you have to specify the helper and know how to run the script. Most users will probably want a command that just takes in a private key location and a profile and requests the cert for them. In case you'd like to look at it now, I have an implementation of that in a separate branch, which I'll create a pull request for after this one is complete: https://github.com/freeipa/freeipa/compare/master...LiptonB:local-cert-build """ See the full comment at https://github.com/freeipa/freeipa/pull/10#issuecomment-243811501 From blipton at redhat.com Wed Aug 31 16:20:08 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 31 Aug 2016 12:20:08 -0400 Subject: [Freeipa-devel] Gettext and CSR generation prompts Message-ID: <494b2279-53b4-c592-4104-521615419f47@redhat.com> Hi, I'm working on adding a feature where some fields of an automatically-generated certificate request can be provided by the user rather than coming directly from the database. In my current implementation, rules that ask for user-specified data are just data rules with the "prompt" option set to a string; this string is displayed to the user to request the data. For example: https://github.com/LiptonB/freeipa/blob/local-user-data/install/share/csr/rules/dataEmailUserSpecified.json I was thinking about internationalization for these prompt strings. We don't need to worry about translating strings in rules that admins define themselves, but if we want to ship any examples of this type of rule with IPA, I was thinking that the prompts might need to be translated. I can wrap the prompt string in _() when the JSON blob is read in, but as the strings are defined in JSON files they still won't be automatically incorporated into the po and pot files, so this won't really do anything. Can you think of a clean way to include these strings when translation files are updated? To see the full implementation, take a look at: https://github.com/freeipa/freeipa/compare/master...LiptonB:local-user-data Thanks, Ben